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ABSTRACT 


This  research  is  part  of  a  year  long  project  commissioned  by  the  Marine  Corps 
Institute  to  develop  the  architecture  and  supporting  migration  plan  to  transition  from  an 
existing  legacy  system  to  an  open,  client/server  based  relational  database  management 
system  (DBMS)  for  the  Student  Services  Department  (SSD).  The  objective  of  this  thesis 
is  to  develop  the  As-Is  process  model,  redesign  the  processes  to  increase  efficiency  and 
reduce  costs,  and  develop  a  To-Be  process  model  to  improve  the  current  business 
processes.  Additionally,  data  flow  diagrams  of  the  To-Be  processes  are  developed  to 
assist  in  prototype  design  and  implementation.  The  DoD  standard  IDEFO  modeling 
technique  is  used  for  developing  the  process  models.  Implementation  recommendations 
include:  (1)  adopting  an  ongoing  reengineering  strategy  at  MCI  supported  by  the 
information  systems  architectures,  methodologies  and  CASE  tools,  and  (2)  utilizing  a 
single  database  to  facilitate  data  sharing  among  MCI  departments,  streamline  processes, 
facilitate  automation,  eliminate  data  redundancy,  and  improve  customer  service. 
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I.  INTRODUCTION 


This  chapter  provides  introductory  information  on  the  purpose  and  content  of  the 
thesis.  It  discusses  the  background  and  objectives  of  the  research,  the  research  questions 
and  methodology  used.  It  defines  the  scope  of  the  thesis,  and  provides  a  list  of  acronyms 
used  throughout.  Finally,  it  outlines  the  content  of  each  of  the  chapters. 

A.  BACKGROUND 

The  Marine  Corps  Institute  (MQ)  was  established  to  "develop,  publish,  distribute, 
and  administer  distance  training  and  education  materials  to  enhance,  support,  or  develop 
required  skiUs  and  knowledge  of  Marines  and  to  satisfy  other  training  and  education 
requirements  as  identified  by  the  Commanding  General,  MCCDC"  (MCI  Mission,  1997). 
To  accomplish  its  mission,  MCI  is  organized  into  seven  functional  departments:  education 
and  operations,  student  services,  information  management  systems,  occupation  specialty, 
professional  military  erlucation,  production,  and  logistics. 

The  mission  of  the  student  services  department  is  to  support  the  enrollment, 
grading  and  management  of  the  Marine  Corps  distance  education  and  training  programs. 

In  support  of  its  mission,  the  student  services  department  employs  an  automated 
information  system  (AIS)  to  automate  the  actions  required  to  support  a  student  in  the 
MCI  correspondence  program,  maintain  student  records,  and  produce  necessary 
management  reports.  The  automated  system,  known  as  the  Marine  Corps  Institute 
Automated  Informati.  -n  System  (MCIAIS),  is  a  legacy  system  developed  in  the  late 
1970's.  It  runs  on  a  Hewlett-Packard  3000  mini  computer  running  the  MPE/iX  operating 
system.  MCIAIS  is  v  i  itten  in  HP  proprietary  language  "Transact"  and  accesses  a  Turbo- 
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IMAGE  hierarchical  database.  As  is  typical  of  many  legacy  systems,  MCIAIS  suffers  from 
many  shortcomings: 

•  It  has  over  110  "spaghetti  coded"  programs  that  are  difficult  to  maintain, 
modify,  and  upgrade. 

•  It  does  not  have  underlying  data  or  process  models. 

•  The  programs  have  poor  functionality,  no  statistical  analysis  capability,  and 
limited  "ad  hoc"  query  capability. 

•  It  utilizes  a  "closed"  non-relational  database. 

•  It  does  not  support  Graphical  User  Interfaces  (GUI). 

In  response  to  these  shortcomings,  MCI  initiated  a  modernization  project  to 
redesign  MCIAIS  using  "open"  system  architecture  (both  hardware  and  software).  In 
addition,  MCI  is  also  reviewing  and  redesigning  the  business  processes  to  better  support 
its  mission  and  current  advances  in  training  and  education.  MCI  contracted  with  the  Naval 
Postgraduate  School  to  perform  an  analysis  and  develop  a  business  process  reengineering 
evaluation  and  migration  plan  proposal.  A  team  of  students  was  selected  by  Dr.  Magdi  N. 
Kamel,  Ph.D.  to  conduct  the  evaluation  and  prepare  the  proposal. 

This  thesis  documents  the  process  redesign  portion  of  the  Student  Services 
Department  (SSD)  information  system.  The  research  was  conducted  from  August  1996 
through  August  1997  The  complete  project  report  is  available  as  the  following  two 
technical  reports. 

•  NPS-SM-97-001:  Analysis,  Design,  and  Prototype  Implementation  of  a 
Contemporary  Information  System  for  the  Marine  Corps  Institute, 
Preliminary  Report  (Kamel  et  al.,  1997) 
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•  NPS-SM-97-006:  Analysis,  Design,  and  Prototype  Implementation  of  a 
Contemporary  Information  System  for  the  Marine  Corps  Institute,  Final 
Report  (Kamel  et  al.,  1997) 

Other  Naval  Postgraduate  School  theses  that  cover  related  aspects  of  the  modernization 
project  include: 

•  Data  model  design:  A  Relational  Database  Model  and  Data  Migration 
Plan  for  the  Student  Services  Department  at  the  Marine  Corps  Institute 
(Slaughter,  1997). 

•  Architecture  model  design:  A  System  Architecture  and  Migration  Plan 
for  the  Student  Services  Department  of  the  Marine  Corps  Institute  (Evers 
Jr.,  1997). 

•  Prototype  design:  Development  of  Graphical  User  Interface  Standards 
and  Prototype  for  the  Student  Services  Department  of  the  Marine  Corps 
Institute  (Hehe,  1997). 

B.  OBJECTIVE 

The  objective  )f  this  thesis  is  to  perform  a  detailed  analysis  of  process 
requirements,  review  existing  processes,  develop  the  AS  IS  process  model,  redesign  the 
processes  to  increase  efficiency  and  reduce  costs,  and  develop  a  TO  BE  process  model  to 
improve  the  current  business  processes  using  IDEFO  models.  Additionally,  data  flow 
diagrams  of  the  To-Be  AIS  were  developed  to  assist  in  prototype  design  and  coding. 

C.  RESEARCH  QUESTIONS 

This  research  was  focused  on  the  following  questions: 

•  Can  a  process  model  be  developed  to  reflect  the  current  business  process  of 
the  Student  Services  Department  of  the  Marine  Corps  Institute  (MCI)? 

•  Can  the  business  process  of  the  Student  Services  Department  of  MCI  be 
reengineered? 

•  Can  a  process  model  be  developed  to  reflect  the  reengineered  business  process 
of  the  Student  Services  Department  of  MCI? 
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•  What  BPR  methodology  is  most  suitable  for  reengineering  the  Student 
Services  Department  of  MCI? 

•  What  CASE  tool  is  most  suitable  for  reengineering  the  Student  Services 
Department  of  MCI? 

•  Can  a  CRUD  diagram  be  developed  to  support  the  BPR  of  the  Student 
Services  Department  of  MCI? 

D.  SCOPE,  LIMITATIONS,  ASSUMPTIONS 

Prior  to  reengineering  a  large  and  complex  organization,  a  business  process 

reengineering  methodology,  a  modeling  technique,  and  supporting  CASE  tools  must  be 
identified.  Once  these  are  chosen,  reengineering  begins  at  the  enterprise  level  and 
progresses  down  through  the  organization  examining  every  process  for  ways  to  improve 
it.  This  thesis  focuses  on  the  process  modeling,  analysis,  and  redesign  of  the  Student 
Services  Department  of  the  Marine  Corps  Institute.  Other  business  areas  at  MCI  identified 
in  the  enterprise  analysis  could  be  analyzed  in  a  similar  fashion  in  future  efforts. 

E.  RESEARCH  METHODOLOGY 

Following  a  literature  survey  of  business  process  reengineering  methodologies,  the 
methodology  adopted  for  this  research  combines  classic  business  process  reengineering 
philosophy  with  information  engineering  techniques  developed  by  James  Martin.  Before 
the  data  gathering  stage  of  the  project,  considerable  time  was  spent  by  the  authors 
evaluating  potential  CASE  tools.  Once  a  CASE  tool  was  chosen,  more  time  was  spent 
developing  expertise  with  the  tool’s  features  and  capabilities.  With  the  technical  ground 
work  laid,  the  authors  each  made  three  trips  to  MCI  to  interview  personnel,  observe  daily 
operations,  and  gather  documents.  Personal  visits  were  augmented  by  telephone 
conversations  and  the  electronic  exchange  of  model  diagrams  and  associated  information. 


The  information  gathered  was  analyzed  and  structured  by  conducting  the  following 
activities:  MCI  enterprise  analysis,  business  area  analysis  of  the  Student  Services 
Department  resulting  in  As-Is  model  development,  logical  redesign  of  the  Student  Services 
Department  processes,  To-Be  model  development,  and  SSD  information  system  model 
redesign.  The  final  result  was  a  proof-of-concept  prototype  fully  described  in  another  team 
member’s  thesis  (Hehe,  1997).  Complete  model  diagrams  and  documentation  are 
contained  in  Naval  Postgraduate  School  Technical  Reports  cited  earlier. 

F.  DEFINITIONS  AND  ABBREVIATIONS 

The  following  definitions  and  abbreviations  are  used  throughout  the  thesis. 


ABC 

Activity  Based  Costing 

AIS 

Automated  Information  System 

ALMAR 

All  Marine  Message 

AVRS 

Automated  Voice  Response  System 

BAA 

Business  Area  Analysis 

BPI 

Business  Process  Improvement 

BPR 

Business  Process  Reengineering 

CASE 

Computer  Aided  System  Engineering 

CIM 

Corporate  Information  Management 

DoD 

Department  of  Defense 

FEA 

Functional  Economic  Analysis 

FPI 

Functional  Process  Improvement 

GUI 

Graphical  User  Interface 
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HQMC  Headquarters,  United  States  Marine  Corps 

ICOM  Input,  Control,  Output,  Mechanism  (acronym  for  all  arrows  on  an 

IDEFO  activity  model) 

IDEFO  Integrated  Definition  for  Information 

Modeling  Language  for  Process  Modeling 

IT  Information  Technology 

LOGAIS  Logistics  Automated  Information  System 

MCC  Major  Command  Code 

MCCDC  Marine  Corps  Combat  Development  Command 

MCI  Marine  Corps  Institute 

MCIAIS  Marine  Corps  Institute  Automated  Information  System 

MCTFS  Marine  Corps  Total  Force  System 

MCU  Marine  Corps  University 

MIS  Management  of  Information  Systems 

MISD  Management  of  Information  Systems  Department 

MOS  Military  Occupational  Specialty 

NCO  Noncommissioned  Officer 

OSD  Occupational  Specialty  Department 

PME  Professional  Military  Education 

PMED  Professional  Military  Education  Department 

RUC  Reporting  Unit  Code 

SNCO  Staff  Noncommissioned  Officer 

SSD  Student  Services  Department 
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SSN 


Social  Security  Number 


UAR  Unit  Activity  Report 

USMC  United  States  Marine  Corps 

G.  ORGANIZATION  OF  STUDY 

Chapter  n  of  this  thesis  is  a  description  of  the  Marine  Corps  Institute,  the 

problems  with  its  current  information  system,  and  the  overarching  MCI  modernization 
project.  Chapter  HI  discusses  the  information  engineering  methodology  developed  by 
James  Martin  and  hov/  it  was  applied  to  the  MCI  modernization  project.  Chapter  IV 
discusses  business  process  reengineering  methodology  and  its  application  to  reengineering 
the  Student  Services  Department  of  MCI.  Chapter  V  is  a  discussion  of  the  IDEFO 
modeling  technique,  functional  decomposition  techniques,  data  flow  diagramming,  and 
CASE  tool  alternatives  that  were  considered  for  use  on  this  project.  Chapter  VI  presents 
the  enterprise  analysis  of  MCI.  Chapter  VII  details  the  business  area  analysis  and  the 
information  system  design  portions  of  the  methodology  to  the  Student  Services 
Department  of  MCI.  Finally,  Chapter  VDI  details  recommendations  for  implementation 
and  further  research,  and  conclusions. 


7 


8 


IL  THE  MCI  MODERNIZATION  PROJECT 

This  chapter  provides  the  details  of  the  Marine  Corps  Institute  (MCI) 
Modernization  Project  performed  by  the  Naval  Postgraduate  School  MCI  Thesis  Team. 
The  chapter  begins  with  a  background  of  MCI,  which  includes  a  discussion  of  its  history, 
mission,  organization  and  description.  The  chapter  introduces  the  MCI  Automated 
Information  System  (MCIAIS)  identifying  the  system  interfaces,  non-system  interfaces, 
and  known  problems.  The  chapter  presents  the  strategic  plan  for  the  enterprise- wide 
modernization  effort  of  MCI.  It  then  discusses  the  Naval  Postgraduate  School  (NPS)  role, 
the  NPS  MCI  team  members  and  their  focused  area  of  research.  The  chapter  concludes 
with  the  benefits  that  MQ  will  reap  from  the  project  presented  in  a  “process  perspective”. 
A.  MCI  BACKGROUND 

MCI  started  as  a  school  house  in  Quantico  with  part-time  Marine  instructors,  but 
quickly  developed  into  an  accredited  correspondence  school.  It  was  established  to  provide 
vocational  training  and  personal  development  through  part-time  education  during  a  period 
of  the  1920s  fraught  vdth  military  indifference.  A  brief  review  of  its  history,  mission, 
organization  and  description  of  services  may  shed  some  light  on  where  its  future  should 
lead.  (MCI  Dream,  1997) 

1.  History 

Lieutenant  General  John  A.  Lejeune  is  often  referred  to  as  “the  greatest  of  all 
Leathernecks.”  Among  his  noteworthy  achievements  during  more  than  40  years  of  service 
include  the  thirteenth  Commandant  of  the  Marine  Corps,  the  first  Marine  to  command  an 
Army  Division,  a  recognized  strategist  and  effective  leader  (Lejeune,  1949).  Lejeune  also 
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established  the  Fleet  Marine  Force,  formalized  Amphibious  Doctrine  (Hough  et  al.,  1997), 
and  founded  the  Marine  Corps  Institute  (MQ  Dream,  1997).  Lejeune  left  an  indelible 
mark  on  the  Marine  Corps  challenging  leaders  to  develop  their  subordinates  much  like 
“fathers  to  sons  or  teachers  to  scholars”(Larson,  1996). 

Exhibiting  that  leadership  against  substantial  resistance,  then  Major  General 
Lejeune  issued  a  Post  Order  on  November  12, 1919,  one  month  after  assuming  command 
of  Marine  Barracks  Quantico,  Virgiitia,  establishing  the  first  three  vocational  schools  in 
the  Marine  Corps.  The  schools  operated  under  the  premise  that  normal  military  duties 
would  be  performed  In  the  morning  and  vocational  training  would  be  available  in  the 
afternoon  on  a  voluntary  basis.  The  Vocational  Training  Schools  Detachment  at  Quantico 
opened  on  January  5,  1920.  Courses  like  Automobile  Mechanics,  Band  Music  and  Playing, 
Blacksmithing,  Carpentry,  Cooking  and  Baking,  Drafting,  Electrical  Mechanics,  Forestry, 
Gas  Engine  Design  and  Operations,  Livestock,  Painting,  Plumbing,  and  Stenography  and 
Clerical  Work  clearly  demonstrated  their  utility  during  that  era.  (MCI  Dream,  1997) 

MCI’s  affiliation  with  correspondence  courses  began  almost  as  soon  as  the 
Vocational  Training  Schools  Detachment  was  established.  The  first  Director,  Lieutenant 
Colonel  William  C.  "Bo"  Harllee,  traveled  to  Scranton,  Pennsylvania  and  made  an 
agreement  with  International  Correspondence  School  (ICS)  to  use  thek  courses  for  the 
instruction  of  Marine  students.  ICS  reviewed  ten  percent  of  the  completed  examinations 
and  Marine  officer  instructors  reviewed  the  rest.  This  arrangement  provided  Marines,  that 
satisfactorily  completed  a  course,  a  completion  certificate  from  ICS  and  co-signed  by  the 
Commandant  of  the  Marine  Corps.  (MCI  Dream,  1997)  This  accreditation  and 
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certification  philosopf.y  remains  with  MCI  today,  as  an  incentive  and  reward  for  Marines 
pursuing  self-improvemenL 

The  correspondence  course  aspect  was  first  implemented  in  May  1920  when 
enrolled  students  at  Quantico  were  transferred  to  the  USS  HENDERSON  and  ordered  to 
counter  a  potential  uprising  in  Mexico.  Lieutenant  Colonel  HarUee  sent  a  school 
representative  with  course  materials  to  the  ship.  The  action  demonstrated  the  need,  and 
intent,  to  support  Marine  education  using  methods  that  do  not  infringe  upon  the  Marine 
warfighting  mission  “in  every  clime  and  place.”  The  popularity  of  self-improvement  was 
reflected  in  increased  enrollments  and  a  recruiting  campaign  that  offered  enlistees  an 
assignment  to  Quanti  'o  where  they  could  enroll  in  one  of  the  schools.  (MCI  Dream,  1997) 

MCI  has  been  moved  and  redesignated  many  times  over  the  last  77  years.  The 
Vocational  Training  Schools  Detachment  was  forced  to  close  the  first  month  it  opened 
because  of  an  influenza  epidemic.  However,  it  reopened  on  the  recognized  founding  date, 
February  2, 1920.  The  Vocational  Training  Schools  Detachment  at  Quantico  was  officially 
designated  as  the  Marine  Corps  Institute  in  July  of  1920  and  moved  to  Marine  Barracks 
Washington,  DC  on  November  10, 1920.  In  January  1926,  military  subjects  were  added  to 
the  available  correspondence  courses.  In  December  of  1946,  it  was  organized  under  the 
Extension  Division,  Marine  Corps  Schools.  In  November  of  1953,  MCI  was  directed  to 
discontinue  its  vocational  courses,  which  were  provided  by  the  U.S.  Armed  Forces 
Institute,  and  focus  only  on  military  subjects.  At  this  time,  the  arrangements  with  ICS 
ended.  In  June  of  1977,  the  National  Home  Study  Council  gave  accreditation  to  MCI.  In 
October  of  1980,  the  Extension  School  and  MCI  was  consolidated  and  all  Marine  Corps 
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training  and  education  correspondence  courses  became  and  the  responsibility  of  the 
Director,  Marine  Corps  Institute.  MCI  moved  to  its  current  location  at  the  Washington 
Navy  Yard  in  November  1993.  Today,  most  MCI  courses  receive  college  credit  through 
American  Council  on  Education  (ACE)  accreditation.  (MCI  History,  1997) 

2.  Mission 

MCI  has  two  missions  that  govern  their  operations:  education  of  Marines  and 

ceremonial  support  to  the  Commandant  of  the  Marine  Corps.  Early  in  its  history,  MCI 

administered  and  distributed  correspondence  courses  developed  by  ICS.  Today,  in 

addition  to  administration  and  distribution,  MCI  must  also  identify  and  develop  the 

courses  that  improve  Marine  proficiency.  This  shift  in  focus  accounts  for  the  evolution  to 

MCI’s  current  mission  (MCI  In-Brief,  1996): 

To  develop,  publish,  distribute,  and  administer  distance  training  and  education 
materials  to  enhance,  support,  or  develop  required  skills  and  knowledge  of 
Marines  and  to  satisfy  other  training  and  education  requirements  as  identified  by 
the  Commanding  General,  Marine  Corps  Combat  Development  Command. 

In  the  earliest  days  of  MCI,  the  staff  performed  their  primary  military  duties  first 

and  volunteered  to  assist  in  the  vocational  schools  as  a  collateral  duty.  Today,  MCI  has  a 

full-time  staff.  Marines  and  civilians,  dedicated  to  course  development  and  administration. 

Not  to  stray  too  far  from  their  roots,  the  Marines  have  retained  collateral  military  duties. 

This  second  mission  of  MCI  results  from  its  administrative  assignment  to  Marine 

Barracks,  Washington,  DC  (MCI  In-Brief,  1996): 

To  support  the  ceremonial  mission  of  Marine  Barracks,  Washington,  DC 

There  are  seven  tasks  that  detail  the  execution  of  the  two  missions  (MCI  Mission,  1997): 
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1.  Plan,  develop,  and  administer  a  distance  training  program  to  increase  the 
specialized  skill  proficiency  of  enlisted  Marines. 

2.  Plan,  develop,  and  administer  nonresident  professional  military  education 
courses  that  parallel  and  supplement  those  resident  courses  provided  by  the 
Marine  Corps  Combat  Development  Command. 

3.  Develop,  print,  stock  and  distribute  the  Marine  Battle  Skills  Training 
Handbook  and  a  performance  test  for  use  by  commanders  to  measure 
proficiency  in  the  Marine  battle  skills. 

4.  Design,  develop,  revise,  stock,  and  distribute  training  materials  for  those  tasks 
contained  in  the  Individual  Training  Standards  system  that  are  the 
responsibility  of  the  unit  commander  to  teach. 

5.  Develop,  print,  stock,  and  distribute  additional  training  materials  as  may  be 
directed  by  the  Commanding  General,  Marine  Corps  Combat  Development 
Command. 

6.  Provide  personnel  and  administrative  support  as  required  for  ceremonial 
piuposes  as  directed  by  the  Commanding  Officer,  Marine  Barracks, 
Washington,  DC. 

7.  Provide  automated  information  support  to  Marine  Barracks,  Washington,  DC. 

These  tasks  specify  Marines  as  the  target  student  population.  They  also  assign 

responsibility  for  the  complete  training  package,  from  development  through  delivery,  to 
MCI.  These  tasks  also  give  an  indication  of  the  organizational  requirements  necessary  to 
successfully  carry  out  the  seven  mission  tasks. 

3.  Organization 

MCI  is  operationally  controlled  by  the  Commanding  General,  Marine  Coips 
Combat  Development  Command  (CG,  MCCDC).  Specifically,  the  Director,  Training  and 
Education  Division,  MCCDC,  provides  operational  guidance  to  MCI.  MCI  receives 
technical  direction  on  Professional  Military  Education  course  content  from  the  President, 
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Marine  Corps  University.  MCI  is  administratively  controlled  by  the  Commanding  Officer, 
Marine  Barracks,  Washington,  DC  who  is  also  the  Director  of  MCI.  (MCI  In-Brief,  1996) 
Marine  Barracks,  Washington,  DC  is  composed  of  a  headquarters  company,  two 
ceremonial  companies  and  the  MCI  company.  The  Barracks  performs  two  evening  parades 
every  week  during  the  summer  and  supports  other  ceremonial  activities  at  the  White 
House.  The  MCI  Company  of  Marine  Barracks  provides  escort  and  support  services  for 
the  parades.  The  MCI  company  consists  of  six  departments:  Headquarters,  Professional 
Military  Education,  Occupational  Specialty,  Logistics,  Student  Services,  and  Management 
Information  Systems.  (MCI  In-Brief,  1996) 

The  Headquarters  Department  has  four  sections  that  provide  staff  cognizance  over 
MCI’s  departments  in  volved  in  the  production  and  support  of  distance  education  and 
training  materials.  The  Professional  Military  Education  Department(PMED)  provides 
courses  based  on  Marine  Corps  resident  PME  school  curricula  or  resident  school 
prerequisites.  The  Occupational  Specialty  Department  (OSD)  develops  and  maintains 
military  occupational  Specialty  (MOS)  related  courses  and  MOS  specific  job  aids.  The 
Logistics  Department  (LOG)  is  responsible  for  the  procurement,  stock  management, 
packaging,  and  distribution  of  MCI  courses  and  training  products.  The  Student  Services 
Department  (SSD)  is  r  esponsible  for  the  enrollment,  grading,  and  student  record 
administration  of  the  distance  education  and  training  programs.  The  Management 
Information  Systems  Department  (MISD)  provides  automated  student  administration  and 
course  material  handling  through  MCI's  automated  information  system  (MCIAIS)  and 
information  systems  support  to  MCI  and  the  Marine  Barracks.  (MCI  Mission,  1997) 
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4.  Description  of  Services 

Since  the  days  of  General  Lejeune,  the  Marine  Corps  has  advocated  personal 
development,  and  MCI  has  been  focused  on  this  objective.  MCI  has  shifted  from  providing 
vocational  and  personal  development  courses  for  uneducated  Marines  in  the  early  days  to 
courses  designed  to  improve  the  performance  of  today’s  more  educated  Marines.  MCI 
currently  maintains  six  PME  courses,  166  Military  Operational  Specialty  (MOS)  related 
courses,  16  MOS  job  rdds,  the  Marine  Battle  Skills  Training  Handbooks  and  the  Battle 
Drill  Guide  books.  These  materials  are  designed  to  enhance  the  student’s  proficiency  in 
their  skill  specialty,  increase  their  awareness  of  Marine  warfighting  concepts  and  tactics, 
and  prepare  them  for  advancement  to  the  next  higher  grade.  (MCI  Mission,  1997) 

The  Marine  Corps  has  emphasized  the  importance  of  completing  MCI  courses  by 
granting  enlisted  Marines  extra  points  toward  promotion  cutting  scores.  This  incentive 
provides  a  more  immediate  benefit  to  an  individual  than  college  credit  and  education. 
(MC01400.32, 1989) 

Professional  Military  Education  (PME)  is  intended  to  ensure  that  leaders  have  the 
knowledge  required  for  their  grade,  and  prepare  them  for  the  next  higher  grade 
(ALMAR26, 1996).  Marine  Corps  University  (MCU)  was  established  to  develop  and 
implement  PME  programs  (Mundy,  1994).  The  Commandant  of  the  Marine  Corps 
announced,  with  the  Ail  Marine  message  (ALMAR)  256-93,  that  promotion  and  retention 
would  be  linked  to  satisfactory  completion  of  PME  requirements  (ALMAR256, 1993). 
MCU  has  established  centralized  resident  PME  schools  and  provides  technical  guidance  to 
MCI  on  the  development  of  non  resident  PME  programs. 
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MCI  programs  were  established  as  the  baseline  for  PME  programs,  serving  as 
either  a  substitute  for  resident  programs  or  fulfilling  prerequisites  prior  to  acceptance  in  a 
resident  program  (ALMAR339-96).  PME  is  so  important  that  unless  a  Marine  has 
completed  the  prescribed  grade-specific  PME  program,  resident  or  non-resident,  he/she 
will  not  be  considered  “fully  qualified”  for  promotion  or  retention  (reenlistment). 
(ALMAR256, 1993) 

Whether  the  guidance  was  seen  as  a  scare  tactic  or  the  result  of  a  successful 
awareness  campaign.  Marines  responded  to  the  non-resident  educational  opportunities 
provided  by  MCI.  On  a  monthly  basis,  MCI  processes  50,000  enrollments,  grades  80,000 
lessons  and  examinations,  prints  and  mails  200,000  individual  status  documents,  56,000 
completion  certificates  and  diplomas,  1,500  Unit  Activity  Reports,  and  produces  45 
internal  management  j  eports.  The  management  of  this  student  record  activity  is  the 
responsibility  of  the  Student  Services  Department.  (MCI  In-Brief,  1996) 

B.  MCI  AUTOMATED  INFORMATION  SYSTEM 

The  mission  of  SSD  is  to  support  the  enrollment,  grading  and  student  record 
management  of  the  Marine  Corps  distance  education  and  training  programs.  In  support  of 
its  mission,  SSD  employs  an  automated  information  system  (AIS)  to  automate  the  actions 
required  to  support  a  student  in  the  MCI  correspondence  program,  maintain  student 
records,  and  produce  necessary  management  reports.  (MCI  Mission,  1997) 

1.  MCIAIS  System  Overview 

The  automated  system,  known  as  the  Marine  Corps  Institute  Automated 
Information  System  (  MCIAIS),  is  a  legacy  system  developed  in  the  late  1970's.  It  uses  a 


16 


Hewlett-Packard  3000  mini  computer  running  the  MPEAX  operating  system.  MCIAIS  is 
written  in  the  Hewlett  Packard  proprietary  language,  "Transact",  and  accesses  a  Turbo- 
IMAGE  hierarchical  database.  MCIAIS  maintains  eight  non-relational  databases  (MCI  In- 
Brief,  1996): 

•  ANSREF  -  contains  aU  answers  and  references  for  every  exam  and  lesson. 

•  ARCHIV  -  contains  student  records  that  have  been  inactive  for  13  months  or 
more. 

•  DBLOGS  -  contains  the  inventory  records  of  courses  and  components. 

•  MCIDB  -  contains  aU  student  course  and  information  records. 

•  MMSDB  -  an  extract  of  the  Marine  Corps’  Manpower  database  that  contains 
information  on  all  active  duty  Marines. 

•  MSEXAM  -  contains  information  on  exam  stock  on-hand  status. 

•  REMPDB  -  an  extract  of  the  Marine  Corps  Reserve’s  Manpower  database  that 
contains  information  on  all  class  HI  reserve  Marines. 

•  S  ALEDB  -  contains  the  raw  data  for  the  Statistical  Analysis  of  Lessons  and 
Exams  Report  (S.A.L.E.  Report). 

These  databases  are  only  accessible  from  terminals  within  the  Student  Services  or  MIS 
Departments. 

2.  System  Interfaces 

System  interface  refers  to  the  ability  of  two  automated  information  systems  to 
exchange  data  directly.  While  MCIAIS  is  a  “closed”  system,  not  originally  designed  to 
interface  with  external  systems,  the  volume  of  transactions  and  the  customer  base  has 
forced  MCIAIS  to  be  modified  so  that  it  can  interact  with  certain  external  systems  to 
reduce  manual  data  entry.  There  are  four  systems  with  which  MCIAIS  interfaces:  Marine 
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Corps  Total  Force  System,  the  Marine  Corps  Unit  Diary  System,  Conversant  and  the 
Logistic  Automated  Information  System. 

The  Marine  Corps  Total  Force  System  (MCTFS)  is  the  database  maintained  by 
Defense  Finance  and  Accounting  Center  (DFAS)  in  Kansas  City  and  contains  all  of  the 
manpower  information  on  Marines,  both  active  duty  and  reservists.  Specified  MCTFS  data 
elements  are  periodically  downloaded  to  populate  MCIAIS.  Specifically,  MCIDB  and 
REMPDB  are  replaced  by  the  download.  This  information  is  used  by  MCI  for  enrollment 
vahdation  and  material  distribution.  The  interface  is  a  labor  intensive  process  that  requires 
NATURAL  computer  language  scripting  and  a  lengthy  daily  download  process  through  a 
host  server  at  MCCT4  in  Quantico,  Virginia. 

The  MCTFS  database  is  updated  by  individual  Marine  Corps  units  using  an  on-line 
system  called  the  Un  .■  Diary.  Marine  Corps  units  submit  Unit  Diary  transactions  to 
MCTFS.  MCTFS  screens  the  transactions  and  posts  the  valid  transactions  to  the  database. 

In  the  case  of  Unit  Diary  transactions  that  request  MCI  enrollment,  disenroUment 
and  completion,  the  validated  transactions  post  to  an  advisory  database.  Transactions  that 
fail  screening  post  to  the  unit’s  Unit  Diary  Error/Advisory  Report.  MCI  downloads  the 
validated  transactions  from  the  advisory  database.  This  is  also  a  labor  intensive  effort  that 
requires  scripting  in  the  computer  language  ROSCOE. 

Once  the  Unit  Diary  transactions  are  downloaded,  they  must  be  formatted  as  input 
to  MCIAIS.  The  transactions  can  error  out  when  they  run  the  program  to  post  the 
transactions  to  MClAiS.  Each  Unit  Diary  transaction  rejected  by  MCIAIS  must  receive  a 
response  to  notify  the  Marine  Corps  unit  of  the  failed  transaction.  The  unit  then  must 
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notify  the  student  of  the  failed  transaction,  research  the  discrepancy,  and  resubmit  the 
corrected  transaction. 

MCI  also  maintains  an  Automated  Voice  Response  System  (AVRS)  called 
Conversant.  This  system  responds  to  a  caller’s  telephone  keypad  entry  of  social  security 
number  and  course  number  and  provides  the  caller  with  course  status.  This  is  an  Oracle® 
database  that  contains  copies  of  records  for  every  student  currently  enrolled  in  an  MCI 
course  or  program.  The  database  is  updated  by  during  a  weekly  cycle  that  downloads,  by 
overwriting,  key  data  element  to  the  Conversant  database. 

The  Logistics  Department  maintains  a  separate  information  system  called 
LOGAIS.  It  provides  tiutomated  management  of  the  fiscal  plan,  organizational  supply, 
logistic  support  and  procurement  of  MCI  materials.  It  also  provides  certain  inventory 
management  functions.  MCIAIS  does  not  interface  directly  with  LOGAIS  for  inventory 
management.  MCIAIS  creates  mailing  labels  with  material  information  and  the  student’s 
address  for  material  distribution.  Periodically,  the  inventory  data  is  manually  input  into 
MCIAIS. 

3.  Non-System  Interfaces 

Non-System  interface  refers  to  interactions  between  an  automated  information 
system  and  another  source  that  is  not  an  automated  information  systems.  This  section  will 
address  six  non-system  interfaces  that  exist  outside  the  MCIAIS:  course  and  program 
development,  course  and  program  advertisement.  Unit  Activity  Reports,  telephone 
inquiries,  U.S.  mail,  and  electronic  mail. 
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MCI  courses  and  programs  are  designed  in  OSD  and  PMED  respectively.  All 
courseware  is  developed  on  PC’s  in  the  respective  departments.  Each  course  is  routed  in 
paper  form  for  editing  and  covuse  content  review.  Once  approved,  the  “proof’  is  prepared 
and  sent  to  the  printer  for  reproduction.  The  new  or  revised  course  is  added  to  the  course 
catalog  and  appropriate  data  elements  manually  entered  into  MCIAIS  pending  receipt  of 
materials.  Students  can  be  enrolled  in  the  new  course  once  the  materials  arrive  and  are 
stocked. 

Availability  of  new  courses  and  revised  courses  must  be  advertised.  Advertisement 
is  done  using  three  methods:  MCI  Course  Catalog,  MCI  newsletters,  and  MCI  mobile 
briefing  teams.  The  MCI  Course  Catalog  is  revised  and  published,  in  paper  form,  annually 
making  it  an  outdated  tool  for  advertisement.  MCI  newsletters  are  published  quarterly  to 
update  Marine  Corps  units  on  the  availability  of  new  or  revised  courses  and  other 
initiatives  at  MCI.  MCI  also  forms  a  team  that  travels  to  major  commands.  The  briefing 
teams  meet  with  the  Marine  Corps  unit  commanders,  training  officers  and  training  non¬ 
commissioned  officers  (NCO)  to  provide  an  update  of  current  initiatives,  training  on 
administrative  procedures  and  changes  to  old  procedures,  and  to  solicit  input  on  MCI 
performance.  The  newsletters  and  the  briefing  teams,  however,  only  reach  a  small  fraction 
of  the  customer  base. 

The  Unit  Activity  Report  (UAR)  is  designed  to  give  the  Marine  Corps  unit 
Commander  visibility  over  the  unit’s  participation  in  MCI  courses  and  programs.  It 
contains  a  summary  section  with  data  compiled  from  enrolled  students  in  each  unit  and  a 
detailed  transaction  history  section  for  each  student  MCI  prepares  a  UAR  for  every 
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Marine  Corps  unit  twice  a  month.  One  report  is  produced  in  paper  form  and  mailed  to  the 
unit  at  the  end  of  the  month.  Another  report  is  produced  in  digital  format  and  stored  on  a 
file  server  for  units  to  download. 

The  UAR  also  serves  as  a  tool  for  reconciliation  between  the  unit  and  MCI.  The 
Marine  Corps  unit  training  NCO  verifies  that  the  unit’s  enrollment  record  matches  MCI’s 
record  reflected  in  the  UAR.  The  training  NCO  annotates  any  discrepancies  or  expected 
changes  on  the  UAR  and  returns  it  to  MCI.  Annotations  would  reflect  that  a  Marine  has 
enrolled  in  a  course  that  has  not  posted,  been  transferred,  completed  a  course,  disenrolled, 
or  is  awaiting  completion  certification.  MCI  manually  processes  the  returned  UARs  by 
inputting  the  corrections  into  the  student’s  record  on  MCIAIS. 

Telephone  inquiries  are  handled  by  the  Student  Services  Department.  The 
Immediate  Assistance  section  of  SSD  has  a  number  of  telephones  staffed  with  clerks  to 
answer  inquiries.  Non-Marine  students,  potential  students  and  Training  NCOs  can  contact 
MCI  with  their  inquiries.  MCI  administrative  procedures  advise  Marine  students  to 
address  their  questions  to  their  unit  Training  NCO  first.  If  unable  to  answer  the  question, 
the  training  NCO  will  contact  MCI  for  resolution.  This  procedure  is  intended  to  minimize 
telephone  calls  to  MC'I. 

MCI  receives  a  large  volume  of  U.S.  mail  on  daily  basis.  This  mail  consists  of 
enrollment  requests,  material  requests,  inquiries,  disenroUment  notification,  returned 
UARs,  and  completed  lesson  or  course  examinations  for  grading.  The  mail  must  be 
opened,  sorted  and  distributed.  This  is  a  manual  and  time  consuming  process. 
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Electronic  mail  is  another  method  of  interacting  with  MCI.  The  volume  of 
electronic  mail  processed  by  MCI  has  grown  significantly  over  the  last  two  years  due  to 
expanded  access  to  the  Internet  and  increased  unit  access  to  the  Marine  Corps’  Banyan- 
vines  network.  Electronic  mail  traffic  consists  of  enrollment  requests,  material  requests, 
status  inquiries,  disenroUment  notification,  and  returned  UARs. 

4.  Problems  with  MCIAIS 

As  is  typical  o^many  legacy  systems,  MCIAIS  suffers  from  many  shortcomings.  It 
utilizes  a  "closed"  non-relational  database.  It  lacks  well-defined  procedures  without 
underlying  data  or  process  models  and  the  code  has  been  poorly  documented.  It  has  over 
110  "spaghetti  coded"  programs  that  are  difficult  to  maintain,  modify,  and  upgrade.  The 
programs  have  poor  functionality,  no  statistical  analysis  capability,  and  luruted  "ad  hoc" 
query  capability.  It  does  not  support  Graphical  User  Interfaces  (GUI).  These  problems 
lead  to  further  questions  about  data  integrity  and  the  credibility  of  the  stored  data. 

Internal  problems  within  MCIAIS  contribute  to  the  loss  of  functionality  within 
some  of  the  databases.  Many  of  the  problems  can  not  be  repaired  because  of  poor 
documentation  and  unrraceable  code  within  the  legacy  system. 

One  example  of  lost  functionality  is  the  SALEDB,  which  provides  the  statistical 
analysis  capability  to  determine  the  quality  and  effectiveness  of  test  questions  and  answers. 
This  capability  provided  critical  information  to  the  distance  training  instractors  (DTI) 
which  develop  and  revise  the  courses  and  examinations. 

The  functionality  of  DBLOGS,  the  inventory  management  system,  is  also  lost.  As  a 
result,  the  Logistics  Department  performs  frequent  cyclic  inventories  and  manually  adjusts 
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the  on-hand  quantity  within  MCIAIS  to  reflect  changes.  In  the  meantime,  the  Logistics 
Department  switched  to  another  logistics  management  system,  ATLASS,  that  provides 
inventory  functions  in  addition  to  functions  not  directly  related  to  the  inventory 
management  of  course  materials. 

The  interface  with  MCTFS  poses  an  additional  problem.  The  procedure  for 
downloading  Marine  student  information  includes  backing  up  the  MCIAIS  MCIDB  and 
REMPDB  databases  and  replacing  them  with  the  downloaded  data.  Any  changes  that 
were  entered  into  the  two  databases  are  not  reflected  in  the  new  data.  This  negates  any 
Marine  student  address  changes  that  have  been  updated  via  telephone,  electronic  mail  or 
UAR  since  the  last  cycle. 

The  UAR  does  not  receive  the  attention  it  was  designed  to  attract.  Due  to 
MCIAIS  obsolescence,  inaccurate  reports  have  been  historically  produced.  With  over 
1500  UARs  produced  monthly,  a  lot  of  manual  data  entry  is  required  to  input  the 
necessary  changes. 

MCIAIS  data  accuracy  was  exacerbated  by  the  UAR  cycle  time.  As  noted,  student 
history  data  was  not  always  accurate.  A  function  of  the  UAR  is  to  reconcile  MCIAIS  data 
with  actual  data  from  Marine  Corps  Units.  The  volume  of  corrections  requiring  manual 
entry  into  MCIAIS  from  UARs  invariably  did  not  get  accomplished  before  the  next  UARs 
were  distributed.  Training  NCOs  became  frustrated  by  MCl’s  apparent  lack  of  response 
and  stopped  returning  UARs.  Without  corrected  UARs,  additional  inaccuracies 
developed.  Innovative  training  NCOs  discovered  that  calling  MCI  and  submitting 
corrections  directly  to  MCI  through  an  immediate  assistance  clerk  was  an  effective 
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method  to  correct  their  unit’s  records.  This  solution  heightened  telephone  congestion 
problems. 

At  a  time  when  MCI  was  experiencing  its  greatest  challenges  with  MCIAIS’s 
ability  to  respond  to  the  increased  volume  pressures  as  MCI  courses  and  programs  became 
requisite  for  promotion,  the  Marine  Corps  introduced  Marine  Mad.  Marine  Mail  is  an 
electronic  mailbox  set  up  for  the  Commandant  to  receive  feedback  about  any  subject 
directly  from  Marines.  MCI  problems  were  a  common  subject  of  Marine  Mail.  This  type 
of  visibility  gave  MCI  an  awareness  of  problems  that  they  could  not  otherwise  document 
and  added  impetus  to  find  solutions.  Many  of  the  MCI  problems  can  be  attributed  to  the 
problems  characteristic  of  legacy  systems. 

One  common  problem  identified  was  poor  responsiveness  and  reliability  when 
emolling  in  MCI  programs.  In  1995,  MCI  initiated  an  enrollment  process  for  active  duty 
and  reserve  Marines  using  the  Marine  Corps  unit’s  Unit  Diary  system.  This  required 
detailed  coordination  with  the  programmers  of  MCTFS  to  establish  prerequisite  screening 
criteria  and  coded  modules.  Despite  the  MCTFS  enrollment  edits,  Unit  Diary  transactions 
that  passed  MCTFS  screening  do  not  pass  the  MCIAIS  screening.  By  shifting  the  data 
entry  tasks  to  the  unit,  nearly  90  percent  of  enrollments  are  now  automated.  Research 
showed  that  it  takes  a  unit  an  average  of  one  week  to  process  and  run  a  Marine's 
enrollment  request  on  the  unit  diary  and  another  week  for  that  request  to  be  processed  and 
posted  on  MCIAIS.  There  was  not  an  effective  or  timely  way  for  MCI  to  inform  a  student 
that  an  enrollment  attempt  failed.  Other  methods  of  enrollment,  such  as  R-1  card  by  mail 
or  the  monthly  Unit  Activity  Report,  are  more  reliable.  Those  methods  are  also  slow 
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because  of  MCI  manual  data-entry  processing  time.  This  demonstrates  the  difficulty  of 
programming  between  systems  with  a  “closed”  system.  (ALMAR51, 1996) 

Another  problem  frequently  identified  was  that  delivery  of  MCI  course  materials 
was  unreliable  and  not  timely.  A  survey  conducted  by  Columbia  Services  Group  identified 
that  faster  service  was  what  MCI  students  wanted  most  from  MCI  (MCIAIS  Brief,  1996). 
Research  attributed  three  causes  to  delivery  problems.  (ALMAR51, 1996) 

First,  the  vast  majority  of  delays  for  material  was  because  MCI  did  not  have  a  valid 
address  or  location  fc:;  individual  Marines.  MCIAIS  was  using  an  outdated  Reporting  Unit 
Code  (RUC)  structure  for  Marine  unit  addresses  instead  of  the  current  Major  Command 
Code/  Reporting  Unit  Code  (MCC/RUC)  stmcture  used  by  the  Marine  Corps  Total  Force 
System  (MCTFS).  The  MCTFS  MCC/RUC  is  updated  every  time  the  unit’s  address 
changes,  as  well  as  when  a  Marine  is  transferred.  Since  MCIAIS  was  using  the  RUC 
stmcture  for  mailing  labels,  which  had  not  been  updated  for  18  years,  materials  were 
shipped  to  the  wrong  address.  Consequently,  MCI  depended  on  the  Commander's  monthly 
Unit  Activity  Report  (UAR)  to  identify  a  Marine's  valid  address.  But  only  60  percent  of 
the  units  returned  their  UAR  to  MCI  every  month.  (ALMAR51, 1996) 

The  second  cause  was  associated  with  Marine  Corps  unit  mail  handling 
procedures.  MCI  addressed  course  materials  to  the  unit  and  the  unit  distributed  the 
materials  to  the  indivuluals.  MCI  research  discovered  that  U.S.  mail  takes  between  three 
to  twelve  days  to  delri  er  course  materials  to  units  around  the  world.  Delays  beyond  that 
were  attributed  to  unit  mail  handling  procedures.  (ALMAR51, 1996) 
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The  third  cause  of  delayed  course  material  delivery  was  attributed  to  replacement 
of  out  of  stock  materials.  MCI  found  that  it  took  up  to  two  months  to  have  course 
materials  printed.  This  is  compounded  by  the  lost  inventory  management  functionality  of 
DBLOGS.  There  was  not  a  reliable  method  to  anticipate  how  soon  the  stock  of  a  course 
would  expire.  Resolution  of  this  problem  within  MCIAIS  will  require  extensive  analysis 
and  coding  to  return  the  functionality  of  DBLOGS  or  establishing  a  direct  system  interface 
withLOGAIS.  (ALMAR51, 1996) 

Yet  another  problem  identified  by  Marine  Mail  was  the  delay  in  the  delivery  of 
final  examinations.  Administrative  procedures  required  the  student  to  complete  the  course 
lessons  and/or  a  review  exam  and  submit  them  to  MCI  for  evaluation  prior  to  issuing  the 
proctored  final  exam.  Once  submitted,  MCI  would  return  the  results  and  the  final  exam  to 
the  unit  Training  NCG  to  administer.  The  same  mailing  address  problems  associated  with 
coiuse  materials  also  hampered  final  examination  delivery.  (ALMAR51,  1996) 

The  last  prob'em  raised  by  Marine  Mail  was  inconsistent  posting  of  a  course 
completion  to  the  Marine’s  official  military  record  at  Headquarters,  Marine  Corps.  MCI 
research  identified  approximately  20  percent  of  course  completions  recorded  in  MCIAIS 
failed  to  post  to  the  MCTFS  record.  When  MCIAIS  transferred  data  to  MCTFS,  data  was 
lost.  This  was  attributed  to  logic  flaws  within  MCIAIS.  This  is  another  example  of  how 
undocumented  “fixes”  in  a  legacy  system  are  difficult  to  trace  or  troubleshoot.  It  also 
demonstrates  the  risk  of  a  “closed”  system  interface  with  another  system.  (ALMAR51, 
1996) 
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MCI  was  established  on  a  foundation  of  “vision”  by  far-sighted  and  resourceful 
innovators.  Over  the  past  ten  years,  the  information  system  could  barely  support  MCI’s 
primary  mission  of  student  record  management,  let  alone  accommodate  changes  necessary 
to  keep  pace  with  advances  in  distance  learning.  Innovation  was  spent  on  creating  courses 
that  the  limited  information  system  could  support.  The  hallmark  of  vision  was  blurred  and 
MCI’s  reputation  was  tarnished.  MCI  was  reacting,  revising  and  distributing  courseware 
that  headquarters  contrived,  instead  of  designing  innovative  ways  to  educate  Marines. 

C.  MCI  MODERNIZATION  PLAN 

In  response  to  the  shortcomings,  MCI  initiated  a  modernization  project  to  redesign 
and  rewrite  MCIAIS  using  "open"  system  architecture,  both  hardware  and  software.  In 
addition,  MCI  began  reviewing  and  redesigning  their  business  processes  to  better  support 
its  mission  and  advances  in  training  and  education. 

1.  Overview 

MCFs  modernization  plan  began  with  a  requirements  analysis  that  identified 
system  design  alternatives.  A  three-phase  strategy  was  developed  from  the  alternatives 
that  planned  for  three  phases  of  transition. 

The  first  phase  focuses  on  transforming  the  information  system  from  the  current 
MCIAIS  to  a  new  MCIAIS-H.  This  plans  for  the  replacement  of  the  “closed”  legacy 
system  with  an  open  system,  relational  database  using  Fourth  Generation  Programming 
Language  (4GL).  The  plan  requires  documentation  of  the  data  and  process  models. 
MCIAIS-H  should  maintain  the  same  functionality  of  MCIAIS-I,  but  adds  capability  to 
send  an  electronic  copy  of  diplomas  to  the  Manpower  Management  Records  Branch 
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(MMRB)  of  Headquarters,  Marine  Corps  (HQMC),  print  mailing  labels  for  individual 
course  components,  use  “selected  grade”  of  a  Marine  to  determine  enrollment  eligibility, 
and  has  the  ability  to  distinguish  between  different  types  of  course  media  (i.e.,  paper, 
diskette,  CD-ROM,  etc.).  MCIAIS-H  should  also  perform  statistical  analysis  of  exams  and 
ad  hoc  reporting  for  management  and  users.  This  phase  includes  plans  to  stand  up  a  non¬ 
interactive  Internet  Home  Page  for  MCI  and  to  upgrade  the  Automated  Voice  Response 
System  (AVRS)  for  enrollment  without  operator  assistance.  (MCI  Redesign,  1997) 

The  second  phase  plans  for  enhancements  to  MCIAIS-II.  The  customer  should 
have  the  ability  to  enroll  or  inquire  over  the  telephone  AVRS  or  Internet  accessing 
MCIAIS-II  directly  without  a  MCI  operator.  MCI  should  have  an  Automated  Help  Desk 
installed.  This  phase  also  includes  the  automation  of  warehouse  operations  and  complete 
integration  with  MCIAIS-II.  (MCI  Redesign,  1997) 

The  third  phase  is  focused  on  development  of  Distance  Learning  Centers  (MCI 
Redesign,  1997).  MCi’s  Distance  Learning  Center  is  connected  to  Training  and  Education 
Division’s  distributed  learning  plan.  Distributed  learning  is  the  use  of  instractional 
technology  to  increase  an  instructor’s  effectiveness  and  provide  a  student-centered 
learning  environment  The  distributed  learning  plan  is  based  on  course  modernization,  end 
user  computers,  and  a  network  infrastructure.  (Eisiminger,  1996) 

2.  NPSRole 

MCI  contracted  with  the  Naval  Postgraduate  School  to  lay  the  foundation  with  the 
modernization  plan’s  first  phase.  A  team  of  NPS  students  was  selected  by  Dr.  Magdi 
Kamel  to  conduct  a  Business  Process  Reengineering  evaluation  and  prepare  a  migration 
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plan  proposal.  Two  reports,  Analysis,  Design,  and  Prototype  Implementation  of  a 
Contemporary  Information  System  for  the  Marine  Corps  Institute,  Preliminary  Report, 
(Kamel  et  al.,  1997)  and  Analysis,  Design,  and  Prototype  Implementation  of  a 
Contemporary  Information  System  for  the  Marine  Corps  Institute,  Final  Report,  (Kamel 
et  al.,  1997),  were  prepared  by  the  NFS  MCI  Team  and  delivered  to  MCI. 

a.  Deliverables 

The  objective  of  the  NFS  effort  is  to  demonstrate  a  methodology  that  can 
assist  MCI  in  transforming  their  current  legacy  information  system  into  a  modem 
environment  that  can  take  advantage  of  contemporary  architectures  and  open 
technologies.  Specifically,  the  NFS  effort  is  to  accomplish  the  following: 

1.  Ferform  a  detailed  data  and  process  requirements  analysis  at  both  the 
enterprise  and  the  Student  Services  Department  business  area  levels 

2.  Review  existing  SSD  processes  and  develop  a  new  model  that  includes 
redesigned  processes  to  increase  their  efficiency  and  reduce  costs 

3.  Develop  £  target  hardware,  software,  and  network  architecture  based 
on  open  systems 

4.  Develop  a  proof-of-concept  prototype  to  validate  the  proposed 
methodology 

5.  Develop  a  data  migration  and  change  management  plan  for  the  new 
system. 

The  first  report.  Analysis,  Design,  and  Prototype  Implementation  of  a 
Contemporary  Information  System  for  the  Marine  Corps  Institute,  Preliminary  Report, 
(Kamel  et  al.,  1997),  develops  an  enterprise- wide  architecture  for  the  use  of  information 
systems  in  support  of  the  MCI  activities.  The  overall  architecture  is  specified  by  defining 
three  types  of  architectures: 
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1 .  Data  Architecture:  Defines  the  major  kinds  of  data  needed  to  support 
MCFs  business.  IDEFIX  modeling  is  used  to  represent  data. 

2.  Functional  Architecture:  Defines  the  major  functions  of  the  enterprise 
needed  to  manage  the  data.  IDEFO  modeling  is  used  to  represent  this 
architecture. 

3.  Technology  Architecture:  Defines  the  technology  platforms  needed  to 
provide  an  environment  for  the  applications  that  manage  the  data  and 
support  business  functions. 

In  addition  to  defining  the  above  architectures,  a  set  of  matrices  is 
developed  showing  the  relationship  between  entities,  functions,  organization  units  and 
locations.  The  information  provided  by  these  matrices  is  intended  to  challenge 
management  to  think  about  its  structure,  mission,  goals,  and  the  information  needed  to  run 


the  MCI  business. 

The  second  report,  Analysis,  Design,  and  Prototype  Implementation  of  a 
Contemporary  Information  System  for  the  Marine  Corps  Institute,  Final  Report,  (Kamel 
et  al.,  1997),  conducts  a  detailed  business  area  analysis  of  the  Student  Services 
Department  (SSD)  and  Management  Information  Systems  (MIS)  functions.  It  presents  a 
business  area  analysis  by  defining  three  types  of  models: 

1 .  SSD  Data  Model:  Defines  the  major  data  entities,  attributes  and  relationships 
used  by  SSD.  IDEFIX  technique  is  used  to  represent  the  data  model. 

2.  SSD  Process  Model:  Defines  the  major  processes  needed  to  manage  that  data 
and  support  the  operations  of  SSD.  IDEFO  modeling  is  used  to  represent  the 
process  m.cdel. 

3.  SSD  Technology  Model.  Defines  the  technology  platform  options  required  to 
provide  an  environment  for  the  applications  that  manage  the  data  and  support 
the  SSD  business  processes. 
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specifically,  the  final  report  develops  detailed  data,  process,  and 
technology  models  for  the  SSD  and  MIS  functions.  The  report  also  includes  the  associated 
design  specifications  for  development  of  information  systems  applications  to  support 
Student  Services,  and  a  generated  Oracle®  relational  database  schema  with  associated 
triggers. 

In  addition  to  defining  the  above  models,  a  proof-of-concept  prototype  of 
selected  applications  was  developed  to  validate  the  methodology,  refine  resulting  models 
and  to  establish  graphical  user  interface  standards  for  use  across  all  MCI  applications. 

b.  Team  Members  and  Research  Topics 

The  effort  by  NFS  faculty  and  five  students  formed  an  integrated  team  to 
support  the  redesign  of  the  Marine  Corps  Institute’s  Automated  Information  System 
(MCIAIS)  using  contemporary  architectures,  methodologies  and  tools.  In  addition  to  the 
two  reports  submitted  to  MCI,  four  theses  are  also  presented. 

Dr.  Magdi  N.  Kamel  is  an  Associate  Professor  of  Information  Systems  in 
the  Department  of  Systems  Management.  He  has  been  at  the  Naval  Postgraduate  School 
since  August  1988.  His  research  interests  are  in  the  areas  of  application  development, 
database  management  systems  and  information  system  architecture.  Since  joining  the 
faculty  at  NFS,  he  has  been  the  principal  investigator  on  several  research  projects  in 
application  development,  database  management  and  expert  systems.  He  is  the  author  of 
numerous  published  papers  on  these  subjects  and  a  driving  force  in  the  NPS  MCI  Team 
activities. 
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Major  Aaron  T.  Slaughter  is  a  U.S.  Marine  Corps  tank  officer.  He  has  a 
Bachelor  of  Arts  in  Political  Science,  presently  in  a  Master  of  Science  Degree  program  for 
Information  Technology  Management  at  the  Naval  Postgraduate  School.  He  has  been 
involved  in  several  research  projects  in  database  management,  application  development 
and  distributed  support  systems.  He  performed  the  data  analysis  and,  working  with  the 
process  model,  produced  the  data  model  and  data  migration  plan  for  the  MCI 
Modernization  Project. 

Major  Clayton  O.  Evers  Jr.  is  a  U.S.  Marine  Corps  communications  officer. 
He  has  a  Bachelor  of  Arts  in  Political  Science,  presently  in  a  Master  of  Science  Degree 
program  for  Information  Technology  Management  at  the  Naval  Postgraduate  School.  He 
has  been  involved  in  several  research  projects  in  network  management,  database 
management,  application  development  and  distributed  support  systems.  He  performed  the 
system  architecture  analysis  and,  using  the  process  model,  produced  the  recommendations 
for  the  target  architecture  and  the  change  management  plan  for  the  MCI  Modernization 
Project. 

Commander  (Select)  Gerald  L.  Hehe  is  a  U.S.  Navy  E-2C  Naval  Flight 
Officer.  He  has  a  Bachelor  of  Arts  in  Business  Management,  presently  in  a  Master  of 
Science  Degree  program  for  Information  Technology  Management  at  the  Naval 
Postgraduate  School.  He  has  been  involved  in  several  research  projects  in  database 
management,  application  development  and  distributed  support  systems.  He  performed  the 
user  interface  analysis  and,  using  the  data,  process  and  information  models,  produced  a 
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prototype  to  demonstrate  the  functionality  of  selected  applications  for  the  MCI 
Modernization  Project. 

Lieutenant  Colonel  (Select)  Kurt  A.  Baden  is  a  U.S.  Marine  Corps  CH- 
46E  pilot.  He  has  a  Bachelor  of  Science  in  Aerospace  Engineering,  presently  in  a  Master 
of  Science  Degree  program  for  Information  Technology  Management  at  the  Naval 
Postgraduate  School.  He  has  been  involved  in  several  research  projects  in  database 
management,  application  development  and  distributed  support  systems.  He  performed  the 
process  analysis  and  produced  the  information  system  modeling  effort  for  the  MCI 
Modernization  Project. 

Major  Gerald  A.  Peters  is  a  U.S.  Marine  Corps  aviation  supply  officer.  He 
has  a  Bachelor  of  Science  in  Political  Science,  presently  in  a  Master  of  Science  Degree 
program  for  Information  Technology  Management  at  the  Naval  Postgraduate  School.  He 
has  been  involved  in  several  research  projects  in  database  management,  application 
development  and  distributed  support  systems.  He  performed  the  process  analysis  and 
produced  the  process  modeling  effort  for  the  MCI  Modernization  Project. 

3.  Business  Process  Model  Benefits 

The  focus  of  this  thesis  is  directed  at  the  reengineering  of  MCI  and  the  resulting 
process  models.  MCI  has  no  prior  model  documentation  on  their  information  system  or 
business  processes.  The  documentation  provided  by  the  two  reports  and  this  thesis  can 
facihtate  commuiucation  between  departments  within  MCI.  The  communication  can 
develop  a  common  understanding  of  department  processes  and  their  inter-relationship  to 
each  other. 
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Such  documentation  is  useful  for  understanding  the  magnitude  of  change  and 
identifies  the  tasks  required  to  migrate  to  the  new  process.  The  documentation  is  dynamic. 
It  wUl,  and  should,  change  to  reflect  continuous  process  improvements.  It  aids  in 
recognizing  previous  problems  and  ensures  those  problems  are  not  repeated  in  new 
processes.  Documentation  can  provide  a  measure  of  the  value  of  a  proposed  innovation. 
Data  collection  provides  situational  awareness.  Given  a  process  objective  of  reducing  cost, 
for  example,  data  collection  would  need  to  include  the  measurement  of  cost  with  which  to 
compare.  (Davenport,  1993) 

Since  MCI  has  no  documentation  on  their  current  system,  the  process  model  can 
serve  as  baseline  documentation  to  support  their  current  phase  of  modernization.  It  also 
provides  a  methodology  that  can  be  used  with  the  subsequent  phases  of  their  redesign 
effort.  The  methodology  employed  was  developed  after  a  broad  spectrum  of  techniques 
were  evaluated  and  selected  one  as  appropriate  to  fit  MCI. 
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in.  INFORMATION  ENGINEERING  APPLICATION  TO  MCI 
This  chapter  describes  the  Information  Engineering  (IE)  methodology  and  its 
relevance  to  the  MCI  modernization  project.  The  first  section  briefly  describes  the  entire 
methodology.  Portions  of  the  methodology  that  pertain  to  this  thesis,  enterprise  analysis, 
business  area  analysis,  and  business  system  design  are  discussed  in  greater  detail.  Details 
of  business  process  reengineering  methodology,  process  modeling,  CASE  tools,  and  data 
flow  diagrams  are  covered  in  later  chapters. 

A.  INFORMATION  ENGINEERING  METHODOLOGY 

James  Martin  originally  conceived  the  information  engineering  methodology  as  a 
development  tool  for  new  information  systems.  Since  IE  provides  a  comprehensive 
framework  for  satisfying  an  organization’s  information  needs,  the  analytical  techniques  can 
also  be  applied  to  the  reengineering  of  existing  systems.  IE  encompasses  all  phases  of  life 
cycle  development  and  implementation.  EE  methodology  models  the  business  process  with 
three  distinct  but  equally  important  models:  a  business  data  model,  documenting  the 
information  and  its  source  used  by  the  business;  a  business  process  model,  that 
decomposes  the  process  into  more  detailed  activities;  and  the  interaction  between  the 
two,  that  defines  the  relationship  between  the  data  and  the  process  models.  Model 
development  begins  with  analysis  of  business  objectives  and  describes  techniques  to  be 
applied  that  yield  executable  applications  in  the  target  environment. 

1.  Information  Engineering  Overview 

Collectively,  information  engineering  is  an  integrated  set  of  tasks  and  techniques 
designed  to  support  the  systems  development  process.  Integration  is  the  crucial  aspect  that 
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accounts  for  successful  outcome.  Integration  is  fostered  by  a  series  of  abstract  layers 
devised  to  provide  different  views  of  the  same  business  model.  Within  this  information 
engineering  framework,  each  layer  serves  as  a  platform  from  which  to  view  the  application 
systems  in  a  different  level  of  detail.  If  the  system  under  evaluation  is  a  new  system,  the 
path  through  the  layers  follows  traditional  system  design  methodology.  However,  if  the 
methodology  is  applied  to  reengineer  an  existing  system,  entry  may  be  made  at  the 
appropriate  level  and  reengineering  improvements  are  pushed  through  to  the  execution 
level.  Figure  1  illustrates  the  IE  layers  and  some  typical  paths  through  them. 


After  lEF™  Technical  Description,  1992. 


The  architectural  layer  models  the  organization  at  the  highest  level  by  examining 
the  business  strategy  and  business  plan.  It  consists  of  three  interlocking  architectures:  a 
data  architecture,  a  process  architecture,  and  a  technology  architecture.  These  three 
architectures  can  be  represented  as  models  and  describe  a  high-level  blue  print  for  meeting 
the  organization’s  goals  and  objectives.  (lEF  Technological  Description,  1992) 
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The  conceptual  layer  models  the  business  process  and  data.  Process  decomposition 
diagrams  and  a  data  model  record  the  organization’s  data  and  activity  definitions,  entities, 
and  business  rules  describing  the  interdependencies.  These  models  functionally  decompose 
the  concepts  introduced  in  the  architectural  level  and  provide  enough  detail  for  analysis. 

The  external  layer  models  system  behavior  from  the  end  user’s  point  of  view.  It 
contains  specialized  information  about  the  conceptual  layer  of  interest  to  the  user,  such  as 
screen  layouts  and  function  key  assignments. 

The  implementation  layer  is  a  specialization  of  the  external  layer.  It  maps  system 
characteristics  to  specific  hardware  and  software  requirements. 

The  execution  layer  is  the  physical  application  of  the  model  developed  in  the 
previous  layers. 

The  premise  of  BE  methodology  is  a  consistent  framework  on  which  many  methods 

and  techniques  can  be  applied  and  coexist.  Conceived  with  software  automation  tools  in 

mind,  information  engineering  methodology  incorporates  a  systems  development 

framework  on  which  to  build  and  possesses  the  following  characteristics:  a  central 

repository  of  modeling  objects  with  stored  meanings  and  defined  relationships;  graphical 

techniques  to  represent  modeling  objects  in  diagrams;  clearly  identified  relationships 

among  diagrams;  and  correlated  definitions  of  modeling  objects  across  diagrams,  offering 

multiple  perspectives  of  the  same  object. 

The  most  important  purpose  of  the  information  engineering  methodology  is 
to  provide  a  framework  within  which  an  integrated  set  of  software  tools 
can  exist  in  harmony.  The  framework  describes  the  logical  connections  and 
constraints  across  the  architectural,  conceptual,  external,  implementation, 
and  execution  layers  of  the  development  life  cycle.  The  task  order,  task 
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structure,  diagramming  conventions  and  semantics  employed  are  secondary 
considerations.  (IEF^m  Technological  Description,  1992) 

It  is  entirely  acceptable  for  practitioners  to  build  alternate  task  lists  that  conform  to  a 

different  development  paradigm  and  stiU  function  within  the  underlying  framework.  Points 

of  departure  generally  hinge  on  a  preference  for  some  practice  rather  than  a  major 

difference  in  vision.  (lEP''^  Technological  Description,  1992) 

2.  Information  Engineering  Pyramid 

With  the  abstract  framework  established,  Martin  illustrates  the  information 
engineering  methodology  as  a  pyramid  which  has  seven  stages  or  levels:  information 
strategy  planning  (ISP),  business  area  analysis  (BAA),  business  system  design  (BSD), 
technical  design  (TD),  construction,  transition,  and  production.  Figure  2  illustrates  the 
levels  of  IE.  Detail  increases  and  scope  decreases  as  stages  are  accomplished.  The 
methodology  is  iterative  and  stages  2  through  6  must  be  repeated  for  each  of  the  business 
areas  defined  in  stage  1.  Stage  7  is  not  reached  until  the  enterprise  has  been  reengineered. 

Stage  1:  Infoimation  Strategy  Planning  (ISP)  -  During  this  stage,  the 
organization  is  examu  ed  at  the  enterprise  level  to  determine  information  needs  and  build 
an  information  strategy  plan  that  is  aligned  with  the  business  plan.  Two  models  are 
created:  a  data  model,  indicating  what  data  items  are  needed  to  perform  the 
organizational  mission,  and  a  high-level  model  of  the  enterprise.  The  enterprise  model  is 
divided  into  business  areas  that  support  the  organizational  mission. 
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Figure  2.  The  Information  Engineering  Pyramid.  After  Martin,  1990A. 


Stage  2:  Business  Area  Analysis  (BAA  j  -  An  As-Is  process  model  is  developed 
using  process  decomposition  techniques  for  one  of  the  business  areas.  The  model  is 
technology  independent. 

Stage  3:  Business  System  Design  (BSD)  -  During  this  stage,  a  business  system  is 
detailed  within  the  chosen  business  area.  Consideration  is  given  to  how  the  user  will 
interact  with  the  business  system,  however,  the  model  remains  technology  independent 
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Stage  4:  Technical  Design  (TD )  -  This  is  the  first  stage  in  which  the  hardware 
environment,  operating  system,  and  database  management  systems  are  examined.  During 
this  stage  the  BAA  and  BSD  are  tailored  to  the  target  computing  environment. 

Stage  5:  Construction  -  During  this  stage,  all  executable  applications  are 
developed.  These  include  programs,  databases,  screen  formats,  and  user  manuals.  These 
applications  will  enable  the  application  system  to  operate  on  the  target  computer 
environment 

Stage  6:  Transition  -  During  this  stage,  the  new  applications  are  installed  m  a 
production  environment.  This  phased  installation  may  involve  replacing  existing  systems 
or  portions  of  systems. 

Stage  7:  Production  -  This  is  the  final  stage  when  all  of  the  business  areas  have 
been  reengineered  and  the  enterprise  realizes  the  full  benefit  of  the  improved  business 
system.  Execution  of  this  final  stage  satisfies  specific  business  needs  identified  during  the 
initial  stage. 

In  addition  to  the  seven  stages,  the  pyramid  is  divided  horizontally.  The  left  side 
represents  data  and  the  right  side  relates  to  activities.  The  horizontal  division  within  each 
of  the  stages  is  useful  in  dividing  the  required  tasks  among  members  of  the  reengineering 
team.  For  example,  the  left  or  data  side  of  the  pyramid  is  associated  with  the  data 
modeler’s  tasks  of  identifying  data  subjects  and  entity  types,  modeling  the  relationships, 
and  normalizing  the  entity  records.  Activity  tasks  such  as  business  area  identification, 
process  decomposition,  and  matrix  development  fall  on  the  right  side.  The  first  two  stages, 
ISP  and  BAA,  create  a  framework  within  which  different  teams  build  different  parts  of  the 
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system  at  different  times.  To  achieve  consistency  among  separate  modeling  and 

development  teams,  the  information  collected  at  all  levels  of  the  pyramid  is  stored  in  a 

central  repository  called  an  encyclopedia. 

Building  the  framework  in  the  top  two  stages  takes  some  time.  Typically, 
information  strategy  planning  for  the  enterprise  takes  six  months.  Business 
area  analysis  takes  four  to  six  months  for  one  area  of  the  enterprise. 

(Martin,  1990B) 

The  remaining  five  stages,  BSD,  TD,  construction,  transition,  and  production  serve  to 
design  and  implement  the  information  system  according  to  the  plan  devised  during  the  first 
two  stages. 

System  construction  does  not  wait  until  the  framework  is  completely  finished. 
Instead,  a  flexible  prototype  is  quickly  built  which  will  allow  quick  retrofitting  as  the 
information  engineering  framework  evolves.  An  objective  of  the  IE  methodology  is  to 
rapidly  build  systems  that  can  be  quickly  modified  by  code  generating  CASE  tools. 

B.  THESIS  METHODOLOGY 

While  the  MCI  modernization  project  is  concerned  with  all  stages  of  the  MCI 
enterprise,  this  thesis  pertains  only  to  the  activity  side,  of  the  top  three  levels  of  the 
information  engineering  pyramid.  Figure  3  illustrates  these  stages.  Appendix  A  contains  a 
detailed  task  list  for  both  the  data  and  activity  sides.  Three  team  member  theses  cover  data 
modeling  and  execution  of  the  remaining  IE  stages  of  the  MCI  modernization  project. 
Integration  of  all  team  member’s  efforts  result  in  the  complete  modernization  plan  for 
MCI.  The  portions  of  the  ISP  and  BAA  stages  of  the  information  engineering 
methodology  that  pertain  to  process  modeling  include:  enterprise  level  analysis  of  MQ, 
business  area  analysis  of  SSD,  and  design  SSD  To-Be  information  system  model. 
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Figure  3.  The  Top  Three  Levels  of  the  Information  Engineering  Pyramid,  After  Martin. 

1990B. 


C.  ENTERPRISE  LEVEL  ANALYSIS  OF  MCI 

Enterprise  level  analysis  results  in  an  overview  of  the  organization.  This  overview 
is  used  by  top  level  managers  and  reengineering  team  to  decide  how  to  proceed  with  the 
modernization  plan.  The  overview  should  not  be  too  detailed.  It  is  used  to  establish  a 
broad  overview  in  a  short  time.  Detail  will  be  added  later  during  the  business  area  analysis 


stage. 


The  top  level  [of  the  pyramid]  might  be  thought  of  as  being  like  an  author 
planning  a  book  and  creating  its  table  of  contents.  He  surveys  the  overall 
contents  of  the  book  and  divides  it  into  parts  and  chapters.  He  decides 
which  chapters  he  should  write  first.  Similarly,  at  the  overview  modeling 
stage  he  scopes  out  the  overall  structure  and  information  needs  of  the 
enterprise,  divides  it  into  areas,  and  decides  which  area  should  first  be 
analyzed  in  detail.  (Martin,  1990B) 
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The  overview  information  is  stored  in  the  CASE  tool  encyclopedia  so  it  can  be  updated 
over  time  and  used  for  further  analysis  as  detail  is  added. 

To  create  an  overview  for  the  enterprise,  data  and  process  information  must  be 
integrated  with  the  business  strategy.  The  reader  will  recall  that  the  information 
engineering  pyramid  is  divided  horizontally  with  data  information  on  the  left  and  process 
information  on  the  right.  Thus  an  enterprise  level  model  is  created  when  the  data  model 
information  on  the  left  and  the  process  model  on  the  right  are  mapped  together  with  the 
strategic  information.  Mapping  is  achieved  with  matrices.  The  matrices  are  analyzed  and 
clustered  to  define  the  business  areas.  There  are  three  steps  to  this  process:  (1) 
identification  of  organizational  units,  locations,  functions,  and  entity  types,  (2)  matrix 
analysis,  and  (3)  identification  of  business  areas. 

1.  Identification  of  Organizational  Units,  Locations,  Functions,  and  Entity 
Types 

This  first  step  documents  the  structure  of  the  organization,  identifies  the  functions 
and  locations  that  perform  the  functions,  and  the  major  data  entities.  To  successfully 
complete  this  step,  it  is  important  to  identify  individuals  to  interview  and  determine  the 
extent  of  data  and  application  sharing  throughout  the  organization.  Information  is 
collected  in  several  ways.  Before  the  first  interview,  team  members  study  the  existing 
organizational  structure,  any  existing  business  models,  data  dictionaries,  task  breakdown 
of  the  organization,  and  other  documentation  available  about  the  organization. 

2.  Matrix  Analysis 

Once  the  information  is  gathered,  matrices  are  created  to  help  assess  the  extent  of 
data  and  application  interaction  and  validate  the  models  for  completeness.  There  are 
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several  matrix  combinations  that  can  be  generated  from  the  gathered  information.  The  four 
matrices  most  useful  to  the  MCI  modernization  project  are:  organization  versus  location, 
organization  versus  function,  location  versus  function,  and  data  subject  versus  function. 
These  matrices,  as  they  pertain  to  MCI,  are  discussed  in  Chapter  VI. 

Of  the  four  matrices,  the  data  subject  versus  function  matrix  is  the  most  revealing. 
This  matrix  maps  the  data  subjects,  developed  in  the  data  model,  to  the  functions  of  the 
enterprise.  The  matrix  is  created  by  listing  the  data  subjects  horizontally  and  the  functions 
vertically.  Each  intersection  is  marked  to  indicate  whether  the  data  subject  is  created,  read, 
updated,  deleted,  or  archived  by  the  functional  area.  The  intersections  are  marked  with  a 
“C,”  “R,”  “U,”  “D,”  or  “A,”  respectively.  For  this  reason  the  matrix  is  often  referred  to  as 
a  CRUD  diagram. 

A  CRUD  diagram  is  useful  for  two  reasons.  First,  several  problems  will  be 
highlighted  immediately.  For  example,  there  may  be  functions  that  do  not  use  any  of  the 
data  subjects  or,  a  data  subject  may  be  created  by  more  than  one  functional  area. 

Secondly,  a  CRUD  matrix  may  be  modified  and  clustered  to  reveal  business  areas. 

Clustering  is  a  techitique  used  to  show  which  functions  and  data  subjects  fit 
naturally  together.  Before  a  CRUD  matrix  can  be  clustered  it  must  be  modified.  First,  the 
rows  of  functional  areas  are  rearranged  in  life-cycle  order  (e.g.,  a  course  is  first  planned, 
then  developed,  managed,  and  finally  archived).  Next,  the  CRUD  matrix  is  simplified  and 
condensed  into  a  "CR  matrix."  A  CRUD  matrix  is  converted  to  a  CR  matrix,  by  creating 
an  identical  function  axis  and  data  subject  axis  on  a  blank  matrix.  However,  when  filling  in 
the  intersections,  all '  C,”  "U,”  "D,”  and  "A"  entries  from  the  CRUD  diagram  are  replaced 
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with  "C"  entries.  All  ’R"  entries  from  the  CRUD  matribc  retain  an  "R"  on  the  CR  matrix. 


The  CR  matrix  can  now  be  clustered. 

Clustering  arranges  the  order  of  the  data  subjects  so  that  as  they  are  read  across 
the  horizontal  axis,  the  data  subject  that  is  created,  updated,  deleted,  or  archived  by  the 
first  function  (reading  down  the  function  axis)  is  moved  to  the  left.  Then  the  data  subject 
created,  updated,  deleted,  or  archived  by  the  second  function  is  moved  to  the  left.  This 
continues  for  all  data  subjects.  This  process  can  be  automated  with  some  CASE  tools.  The 
resulting  matrix  has  all  the  "Cs"  arranged  on  a  diagonal  line  ruiming  from  the  top-left  to 
the  bottom-right.  The  data  subjects  can  now  be  grouped  by  boxing  the  clusters  as  shown 
in  Figure  4.  The  boxes  represent  logical  information  subsystems  with  responsibility  for 
creating  and  maintaining  the  data  subjects.  When  data  use  falls  outside  of  any  box,  the 
functions  inside  the  box  must  access  the  data  subject  elsewhere,  or  the  data  must  flow 
from  one  subsystem  to  another.  These  subsystems  will  later  be  defined  as  business  areas. 

3.  Identification  of  Business  Areas 

As  a  result  of  clustering,  eight  business  areas  were  identified  for  MCI:  personnel 
administration,  ceremonial  support,  program  and  course  management,  program  and  course 
development,  student  service  support,  warehouse  and  distribution,  information  systems 
management,  and  unit  interaction.  These  business  areas  are  described  in  Chapter  VI.  At 
this  point  business  area  analysis  (BAA)  techniques  are  applied  to  develop  the  process 
model  and  reengineer  rhe  business  processes. 
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Figure  4.  Portion  of  a  Clustered  CR  Matrix. 


D.  BUSINESS  AREA  ANALYSIS  OF  SSD 

The  heart  of  business  area  analysis  is  development  of  the  process  model.  The 
enterprise  level  analysis  resulted  in  business  area  identification.  Once  the  business  areas  are 
identified,  one  of  them  must  be  selected  as  the  first  to  be  analyzed.  If  resources  are  not 
available  to  analyze  them  concurrently,  the  others  will  be  analyzed  in  turn  until  the  entire 
enterprise  has  been  searched  for  reengineering  opportunities.  The  selection  of  the  first 
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business  area  for  analysis  is  left  up  to  the  reengineering  team  and  should  be  based  on  the 
following  factors.  (Martin,  1990B) 

•  Demand:  pressure  of  demand  from  senior  end  users  for  new  or  improved 
systems,  assessed  need,  and  political  overtones 

•  Organizational  impact:  number  of  organizations  and  people  affected,  whether 
the  organization  is  geographically  dispersed,  and  qualitative  effect 

•  Existing  systems:  adequacy  or  value  of  existing  systems,  relationship  with 
existing  systems,  and  estimated  cost  of  future  maintenance 

•  Potential  benefit:  return  on  investment,  achievement  of  critical  success  factors, 
achievement  of  goals,  and  solution  to  serious  problems 

•  Likely  success:  complexity,  degree  of  business  acceptance,  length  of  project, 
prerequisites,  and  risks 

•  Resources  required:  whether  existing  data  or  process  models  exist,  whether  a 
suitable  CASE  tool  is  installed,  quality  of  available  analysts,  and  funds  required 

•  Concurrent  implementation:  whether  multiple  BAA  projects  can  proceed 
concurrendy,  whether  one  project  will  train  people  who  can  quickly  move  onto 
other  projects,  and  whether  an  existing  data  administration  function  has  already 
done  adequate  data  modeling 

Development  of  the  process  model  is  accomplished  through  functional  decomposition. 
Process  modeling  and  functional  decomposition  are  discussed  in  Chapter  V. 

1.  As-Is  Process  Model 

The  As-Is  process  model  emerges  from  the  process  decomposition  of  each 
business  area.  Much  of  the  material  gathered  during  the  enterprise  level  analysis  (e.g., 

MCI  department  briefs,  user  interviews,  training  manuals,  and  management  reports,  etc.) 
is  further  scrutinized  to  define  the  lower  level  processes  in  detail.  Business  areas  are 
broken  down  to  their  primitive  level  processes  with  the  aid  of  a  CASE  tool  which  provides 
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a  repository  for  all  of  the  processes,  their  definitions  and  relationships.  The  process  model 
includes  both  manual  and  automated  processes.  The  As-Is  model  consists  of  three  parts: 
(1)  process  node  tree  diagrams  indicating  process  hierarchy,  (2)  process  decomposition 
diagrams  depicting  the  processes  and  the  data  or  material  they  share,  and  (3)  definitions  of 
all  of  the  symbols  on  each  of  the  diagrams.  IDEFO  techniques  are  used  for  As-Is  process 
modeling  and  discussed  in  Chapter  V. 

2.  Reengineer  the  SSD  As-Is  Process  Model 

Once  the  As-*s  process  model  is  created  and  validated  by  the  process  owner,  the 
reengineering  principles  that  best  fit  the  situation,  are  applied.  The  goal  of  reengineering  is 
to  reorganize  the  organization  around  the  key  processes  performed  by  the  business.  Most 
reengineering  methodologies  investigate  ways  to  eliminate  non- value-added  processes, 
minimize  redundant  data  entry  and  storage,  integrate  or  combine  similar  processes, 
implement  data  sharing,  and  automate  manual  processes.  Business  process  reengineering 
methodologies  are  discussed  in  Chapter  IV. 

3.  To-Be  Process  Model 

The  To-Be  process  model  is  the  result  of  reengineering  the  As-Is  process  model. 
The  To-Be  model  is  often  a  streamlined  version  of  the  As-Is  process  model,  but  in  all 
cases  represents  a  muve  efficient  reincarnation  of  the  former  organization.  Like  the  As-Is 
process  model,  the  To-Be  process  model  is  modeled  using  an  appropriate  modeling 
technique  and  consists  of  three  parts:  (1)  process  node  tree  diagrams  indicating  process 
hierarchy,  (2)  process  decomposition  diagrams  depicting  the  processes  and  the  data  or 
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material  they  share,  and  (3)  delBnitions  of  all  of  the  symbols  on  each  of  the  diagrams. 
IDEFO  techniques  are  used  for  To-Be  process  modeling  and  discussed  in  Chapter  V. 

4.  Matrix  Analysis 

Matrix  analysis  techniques  are  again  applied  to  validate  the  process  and  data 
models  and  lay  the  ground  work  for  the  next  level  of  the  information  engineering  pyramid, 
business  system  design.  Once  the  To-Be  process  model  and  the  data  model  are  complete, 
a  matrix  is  created  that  shows  the  relationship  between  business  processes  and  data  model 
entities.  The  matrix  is  first  generated  as  a  CRUD,  converted  into  a  CR  matrix  and  then 
clustered  as  described  earlier.  The  matrix  analysis  is  used  for  three  piuposes:  (1)  to  ensure 
that  all  of  the  data  model  entities  are  created,  read,  updated,  deleted,  and  archived  by  the 
process  model,  (2)  to  ensure  that  the  data  model  contains  only  the  entities  required  by  the 
process  model,  and  (3)  to  support  the  clustering  of  related  processes  into  groups  that 
reveal  candidate  applications  to  be  distributed  to  the  workstations  in  the  overall 
client/server  system.  Five  applications  were  identified  for  SSD  during  this  step:  student 
servicing,  unit  servicing,  grading,  registrar,  and  executive  summary  information. 

E.  SSD  TO-BE  INFO  SYSTEM  MODEL 

The  information  system  model  represents  that  portion  of  To-Be  process  model  that 
transfers  or  transforms  data  within  the  system.  Manual  processes  are  not  included.  Like 
the  case  of  the  As-Is  and  the  To-Be  business  models,  a  visual  presentation  is  more  useful 
than  a  verbal  description.  IDEFO  can  be  used  for  modeling  the  information  system. 
However,  a  more  common  form  of  information  system  model  depiction  is  with  a  logical 
data  flow  diagram  (D)^D).  The  information  system  model  integrates  the  data  model  details 
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with  the  automated  processes  and  presents  them  in  a  form  that  can  be  interpreted  by  a 
programmer  developing  code  for  a  prototype  system.  The  information  system  model 
consists  of  three  parts:  (1)  DFDs  depicting  information  system  process  decomposition, 

(2)  definitions  of  all  of  the  symbols  on  each  of  the  diagrams,  and  (3)  process  specifications 
at  the  primitive  process  level.  Data  flow  diagramming  is  discussed  in  Chapter  V. 

F,  CASE  TOOL 

Information  engineering  is  made  practical  by  the  use  of  a  CASE  tool.  It  is 
important  to  choose  a  tool  in  which  planning,  analysis,  design,  modeling,  and  construction 
modules  are  integrated  and  share  the  same  encyclopedia.  The  metadata  in  the  encyclopedia 
resulting  from  the  ISP  study  is  a  valuable  asset  and  should  be  updated  periodically.  As  the 
strategic  goals  or  objectives  of  the  business  change,  the  information  in  the  encyclopedia 
should  also  be  changed.  In  this  way,  the  business  model  remains  current  and  available  for 
periodic  review.  The  ISP  should  be  reviewed  periodically  along  with  goals,  problems, 
critical  success  factors,  and  technology  impact  effects  to  ensure  they  remain  in  synch  with 
the  strategic  vision  and  business  plan.  A  suitable  CASE  tool  facilitates  this  analysis.  CASE 
tools  are  discussed  in  Chapter  V. 
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IV.  BUSINESS  PROCESS  REENGINEERING  METHODOLOGY 

This  chapter  presents  a  discussion  and  comparison  of  business  process 
reengineering  (BPR)  methodologies  and  their  relevance  to  the  MCI  modernization  project. 
The  first  section  introduces  business  process  reengineering  concepts.  The  second  section 
briefly  describes  four  prominent  BPR  methodologies.  The  third  section  compares  the 
methodologies.  Finally,  the  fourth  section  evaluates  each  of  the  BPR  methodologies  in  the 
context  of  MCI  and  selects  the  BPR  methodology  best  suited  for  reengineering  the 
Student  Services  Department  of  the  Marine  Corps  Institute. 

A.  REENGINEERING  METHODOLOGY  OVERVIEW 

There  are  many  accepted  reengineering  methodologies.  Some  of  the  more  notable 

methodologies  include:  Process  Innovation,  Business  Process  Improvement,  Business 
Process  Redesign,  and  Business  Process  Reengineering.  Each  methodology’s  approach 
differs  by  the  degree  c  f  change  and  duration  of  implementation.  Although  the  techniques 
of  execution  vary,  the  goal  is  ultimately  the  same:  reorganize  the  organization  around  the 
key  processes  performed  by  the  organization.  Most  reengineering  methodologies 
investigate  ways  to  eliminate  non- value-added  processes,  utilize  information  technology  to 
minimize  redundant  data  entry  and  storage,  integrate  or  combine  similar  processes, 
implement  data  sharing,  and  automate  manual  processes. 

The  generic  term  business  process  reengineering  has  evolved  from  Michael 
Hammer’s  original  radical  overhaul  methodology  to  include  the  full  spectrum  of  many  less 
severe  process  improvements.  Figure  5  illustrates  the  fact  that  as  the  process  modifications 
become  more  significant  there  is  a  also  an  increase  in  project  cost. 
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Figure  5.  BPR  Spectrum. 

expectations,  risk  of  failure,  and  time  to  complete  the  venture.  A  survey  of  four 
methodologies  provides  a  broad  spectrum  of  possibilities  and  capabilities  for  reengineering 
the  Student  Services  Department  at  MCI.  Four  methodologies  are  briefly  discussed  in  the 
succeeding  section.  While  each  methodology  is  unique  in  its  detailed  execution,  they  all 
share  common  elements:  organizing,  team  building  and  planning,  documentation  of  the 
current  process,  analysis,  redesign,  information  technology  application,  implementation 
and,  monitoring. 

B.  REENGINEERING  METHODOLOGY  REVIEW 

Four  BPR  methodologies  were  reviewed  as  candidates  for  the  MCI  modernization 

project:  Hammer  and  Champy’s  Business  Process  Reengineering,  Thomas  Davenport’s 
Process  Innovation,  H.  James  Harrington’s  Business  Process  Improvement,  and  DoD’s 
Functional  Process  Improvement  (FPI).  Each  is  briefly  described  below.  The  order  in 
which  the  methodologies  are  discussed  represent  the  operationalism  of  the  BPR  process. 
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beginning  with  Hammer  and  Champy’s  principles  and  progressing  to  the  Functional 
Process  Improvemen  r  designed  to  be  implemented  with  an  integrated  suite  of  CASE  tools. 
Details  of  each  methodology  can  be  found  in  Appendix  A. 

1.  Hammer  and  Champy 

Michael  Hammer  was  the  first  to  popularize  the  concept  of  reengineering  when  he 
wrote  the  article,  “Reengineering  Work:  Don't  Automate,  Obliterate"  (Hammer,  1990)  for 
the  Harvard  Business  Review.  Hammer  maintains  that  traditional  “total  quality” 
approaches  to  process  improvement  are  insufficient  in  today’s  competitive  market. 
Hammer’s  point  is  actually  a  caution  to  all  reengineering  projects  not  to  blindly  apply 
technology  before  analyzing  the  business  process  first.  Misapplication  of  information 
technology  is  often  a  hindrance  and  Hammer  counters  that  an  organization  must  first 
recognize  its  problerr  •'  and  then  “dramatically”  overhaul  the  way  it  does  business.  This 
dramatic  overhaul  requires  a  completely  fresh  approach  in  order  to  accomplish  the 
objective.  All  preconceived  notions  of  organizational  structure,  decision  making,  and  final 
product  delivery  must  be  ignored  and  a  new  way  of  doing  business  must  be  conceived. 

In  1993,  Hammer  co-authored  Reengineering  the  Corporation  with  James 
Champy.  In  the  book  they  formally  defined  reengineering  as  “the  fundamental  rethinking 
and  radical  redesign  of  business  processes  to  achieve  dramatic  improvements  in  critical, 
contemporary  measures  of  performance,  such  as  cost,  quality,  service,  and  speed” 
(Hammer  and  Champy,  1993).  Reengineering  requires  the  organization  to  consider  the 
final  product  of  its  e.'?  orts,  and  include  information  technology  as  a  requirement  of 
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success.  While  information  technology  can  be  very  useful,  it  should  not  be  apphed 
haphazardly. 

Hammer  and  Champy’s  approach  to  reengineering  is  to  start  with  a  clean  slate  and 
concentrate  on  goods  and  services  producing  processes,  seeking  to  provide  orders-of- 
magnitude  level  improvement  as  opposed  to  incremental  improvements  through  total 
quality  management  principles.  Their  approach  stresses  the  need  for  competition  analysis, 
customer  feedback,  and  strong  organizational  desires  to  succeed.  While  they  lay  out  the 
principles  of  reengineering  and  provide  numerous  examples  of  corporations  that 
successfully  diagnosed  and  corrected  their  own  quality  and  market  performance 
deficiencies.  Hammer  and  Champy  shy  away  from  individual  business  task  analysis  and  do 
not  provide  many  concrete  techniques  that  reengineering  teams  can  apply  to  their  own 
organizations.  While  the  case  studies  iUustrate  the  successful  apphcation  of  Hammer  and 
Champy’s  reengineering  principles,  each  of  the  corporations  is  different  and  the  individual 
techniques  apphed  by  each  to  turn  itself  around  may  not  be  appropriate  for  another. 

2.  Thomas  Davenport 

Thomas  Davenport’s  Process  Innovation  concentrates  on  process  analysis.  Process 
Innovation  is  dividec  nto  five  phases:  identify  processes  for  innovation,  identify  change 
levers,  develop  process  vision,  understand  existing  processes,  and  design  and  prototype 
the  new  process.  Davenport’s  five  phases  guide  the  reengineering  team  through  a 
thorough  search  for  processes  in  need  of  streamhning,  with  particular  interest  in  the 
application  of  information  technology.  Like  Hammer  and  Champy,  Davenport  uses  a 
“clean  slate”  approach  and  stresses  that  incremental  improvements  to  business  processes 
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are  not  enough  in  today’s  intensely  competitive  global  markets  (Davenport,  1993). 
Davenport’s  goal  is  to  make  the  organization  more  profitable,  efficient  and  more  satisfying 
to  customers  by  any  means,  be  it  organizational  structure  changes,  application  of 
information  technology,  or  changing  the  very  nature  of  the  business.  Davenport’s 
methodology  contains  more  techniques  than  does  that  of  Hammer  and  Champy. 

Phase  I,  identify  processes  for  innovation,  begins  with  developing  a  list  of  the  10  - 
20  key  organizational  processes,  defining  these  processes  and  noting  any  interdependence 
between  them.  Each  process  on  the  list  is  then  examined  to  determine  its  strategic  value  to 
the  organization’s  goals,  health,  and  the  political  and  cultural  pressures  associated  with  it. 
Phase  I  concludes  with  a  prioritized  list  of  candidate  processes  for  reengineering.  The 
process  that  is  most  central  to  the  company’s  overall  goals,  most  problematic,  and  has  the 
political  backing  of  organization  leaders  should  be  the  first  entry  on  the  list.  The  other 
processes  will  follow  as  resources  permit. 

Phase  n,  identify  change  levers,  surveys  the  potential  technological  and  human 
opportunities  available  to  change  the  process.  An  important  aspect  of  this  phase  also 
examines  potential  constraints  and  barriers  to  process  change.  Examples  of  constraints  and 
barriers  include,  “strict  hierarchical  structures,  cultures  unreceptive  to  innovation,  and 
general  organizational  rigidity  or  inability  to  accommodate  change”  (Davenport,  1993). 
Both  opportunities  and  constraints  are  considered  and  the  best  change  lever  is  selected. 

Phase  m,  develop  process  vision,  includes  identification  of  measurable  objectives 
and  characteristics  of  the  process,  and  formulation  of  specific  process  attributes.  First,  the 
organization’s  current  vision  and  business  strategy  are  compared  to  the  company’s  desired 
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future  state.  Second,  customer  feedback  is  collected  to  correlate  effort  and  results.  The 
process  is  then  benchmarked  against  similar  processes  of  competitors.  New  performance 
measures  are  then  created  for  the  process  that  will  satisfy  current  customers,  take  the 
organization  where  it  wants  to  be,  and  meet  or  exceed  competition  quality. 

Phase  IV,  understand  existing  processes,  documents  and  models  the  existing 
process  to  use  as  a  baseline  for  evaluating  proposed  process  improvements.  To  accomplish 
this,  the  current  process  is  assessed  with  the  improved  process  criteria  developed  from  the 
previous  phase.  Shoric-omings  not  only  in  process  work  flow,  but  organizational  structure, 
information  infrastmcture,  and  employee  skill  levels  are  identified  and  short  term 
improvements  are  explored. 

Phase  V,  design  and  prototype  the  new  process,  is  the  implementation  stage. 
Design  alternatives  are  enumerated.  After  assessing  each  alternative  for  feasibility,  risks, 
and  benefits,  the  preferred  redesign  is  prototyped.  Following  successful  prototype 
evaluation,  a  migration  strategy  is  developed  and  the  improved  process  is  implemented. 

3.  H.  James  Harrington 

H.  J.  Harrington’s  five  phases  of  Business  Process  Improvement  (BPI)  are  less 
radical  than  that  of  Hammer  and  Champy,  or  Davenport  and  reflect  more  of  a  total  quality 
approach.  Harrington  theorizes  that  management  spends  too  much  time  correcting 
problems  that  should  not  have  occurred  in  the  first  place.  Business  managers  should  now 
be  responsible  for  developing  business  and  manufacturing  processes  that  work  error-free. 
Existing  business  processes  should  be  redesigned  to  error-free  standards.  Throughout  the 
entire  methodology,  Harrington  emphasizes  the  necessity  of  proper  training  for  those 
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executives  and  employees  who  perform  the  analysis  and  process  reengineering.  Harrington 
addresses  five  phases:  organizing  for  improvement,  understanding  the  process, 
streamlining,  measurement  and  control,  and  continuous  improvement. 

Harrington’s  objective  of  Phase  1,  organizing  for  improvement,  is  to  ensure 
success  by  building  leadership,  understanding,  and  commitment  (Harrington,  1991). 

During  this  phase,  the  organization  appoints  an  executive  improvement  team  to  act  as  a 
steering  committee  and  a  business  process  improvement  czar  to  be  responsible  for 
overseeing  the  project  through  to  fruition.  This  high-level  management  group  determines 
the  scope  of  the  project,  establishes  the  level  of  organizational  commitment,  and  appoints 
the  process  improvement  team  (PIT).  Members  of  the  PIT  are  appointed  from  the 
departments  who  own  the  processes  being  reengineered.  The  PIT  members  carry  out  the 
modeling,  analysis,  and  reengineering  of  each  business  process. 

Phase  n,  understanding  the  process,  is  the  data  collection  and  modeling  stage  of 
the  methodology.  PIT  members  examine  business  strategy,  interview  customers,  define 
and  model  business  processes  with  flow  charts  and  documentation  to  develop  what  is 
known  as  an  As-Is  bu  iiness  model. 

Phase  in,  streamlining,  is  where  the  actual  reengineering  takes  place.  PIT 
members  seek  to  ider  tify  process  improvement  opportunities  by  eliminating  bureaucracy 
and  no-value-added  activities,  simplifying  the  process,  reducing  process  time,  upgrading 
equipment,  standardizing  data,  or  automating  activities  (Harrington,  1991). 

The  objective  of  phase  IV,  measurement  and  control,  is  to  implement  a  system  to 
control  the  process  for  ongoing  improvement  (Harrington,  1991).  Once  the  process  has 
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been  reengineered,  process  targets  are  established  by  which  performance  of  the  improved 
process  will  be  measured. 

Phase  V,  continuous  improvement,  embraces  total  quality  principles  by 
continuously  monitoring  the  improved  business  process  for  continued  excellence.  Periodic 
examination  of  the  process  performance  is  benchmarked  against  the  best  practices  in 
industry  and  if  need  be,  the  process  improvement  cycle  is  repeated. 

4.  DoD  Functional  Process  Improvement  (FPI) 

The  functional  process  improvement  program  was  established  in  January  1992  by 
the  Corporate  Information  Management  (CIM)  Information  Technology  Policy  Board  to 
assist  Department  of  Defense  agencies  in  making  improvements  to  their  business 
processes.  FPI  is  the  .most  comprehensive  of  the  BPR  methodologies  discussed  thus  far. 
The  CIM  mandates  that  FPI  create  As-Is  process  models  with  the  IDEFO  technique.  The 
FPI  also  evaluates  potential  process  improvement  alternatives  using  activity  based  costing 
techniques.  During  tlie  final  phase  of  the  FPI  methodology,  a  functional  economic  analysis 
(FEA)  is  prepared  by  the  reengineering  team  for  the  decision  makers.  A  FEA  is  a 
“business  case”  that  presents  the  alternatives  in  business  and  economic  terms  more 
understandable  to  the  majority  of  senior  executives. 

FPI  attempts  to  integrate  six  underlying  principles:  strategicA^usiness  planning, 
activity  modeling,  data  modeling,  activity  based  costing,  economic  analysis,  and  best 
business  practices.  SLx  major  steps  describe  the  FPI  methodology.  The  methodology  is 
further  subdivided  into  enabling  tasks  described  in  Appendix  A. 
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a.  Underlying  FPI  Principles 

StrategicIBusiness  Planning  -  Strategic  planning  provides  a  set  of  business 
goals  and  defined  requirements  expressed  in  terms  of  customer  needs  within  the  context  of 
agency  mission,  vision,  values,  and  beliefs.  A  strategic  plan  defines  what  an  organization  is 
all  about,  who  it  will  serve,  what  needs  it  will  fulfill,  and  under  what  terms  it  wiU  operate. 
A  unique  requirement  of  the  governmental  hierarchy  is  that  the  strategic  plan  must  be 
consistent  with  those  of  higher  authority,  and  no  element  of  the  strategic  plan  can  conflict 
with  the  mission,  vision,  values  and  beliefs  expressed  by  higher  authority.  On  the  other 
hand,  business  planning  provides  a  set  of  business  objectives  with  appropriate  performance 
measurements  and  a  comprehensive  list  of  required  output  product  and  service  features 
that  will  meet  the  customer  needs  defined  in  the  strategic  plan.  The  business  plan  should 
focus  on  what  the  organization  will  do  to  satisfy  the  goals,  needs  and  requirements 
expressed  in  the  strategic  plan. 

Activity  Modeling  -  Activity  modeling  is  a  technique  used  to  understand 
the  business  process.  Process  decomposition  is  used  to  decompose  a  process  into 
activities.  The  result  i.s  a  multi-level  diagram  representing  the  business  process  with  all  of 
the  inputs,  outputs,  controls,  and  mechanisms  affecting  the  final  product  or  service.  This 
final  model  is  referred  to  as  the  As-Is  process  model.  The  As-Is  model  will  be 
reengineered  to  become  the  To-Be  process  model.  The  To-Be  model  will  eventually  be 
used  to  develop  a  prototype  and  implement  the  improved  business  process. 

Data  Modeling  -  Data  modeling  is  a  technique  for  systematically  describing 
what  information  the  organization  needs  to  perform  its  business  process.  Like  activity 
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modeling,  an  As-Is  model  is  &st  produced,  describing  the  current  data  environment.  The 
As-Is  data  model  is  then  analyzed  and  compared  with  the  As-Is  process  model  to  ensure 
that  all  required  data  is  included  and  conversely,  that  no  redundant  or  unused  data  is 
collected  or  maintained.  A  data  model  shows  all  of  the  entities,  attributes,  and 
relationships  among  the  entities.  Entities  are  objects  which  an  organization  values  enough 
to  keep  data  about.  Attributes  are  the  data  items  recorded  about  the  entities.  Relationships 
between  and  among  entities  are  often  expressed  as  business  rules.  To  ensure  compatibility 
with  the  process  modeling  technique,  FPI  mandates  that  data  modeling  be  done  with  the 
IDEFIX  technique.  A  complete  description  of  data  modeling  is  contained  in  A  Relational 
Database  Model  and  Data  Migration  Plan  for  the  Student  Services  Department  at  the 
Marine  Corps  Institute  (Slaughter,  1997). 

Activity  Based  Costing  -  Activity-based  costing  (ABC)  is  a  technique  that 
allows  unit  cost  determination  of  producing  goods  and  services.  ABC  is  an  extension  of 
activity  modeling.  IDEFO  activity  modeling  is  designed  to  record  activity  cost  data.  Unit 
cost  figures  resulting  from  ABC  are  the  basis  for  economic  analysis. 

Economic  Analysis  -  Economic  analysis  provides  the  capability  to  assess 
the  costs  and  benefits  associated  with  each  process  improvement,  taking  into  account  the 
life  cycle  characterist'cs  of  each  investment.  The  As-Is  process  model  is  used  as  a  basehne 
by  which  all  competing  alternatives  are  compared.  Economic  analysis  presents  the  decision 
data  in  equally  valued  dollars  (taking  the  time  value  of  money  into  consideration),  as  well 
as  the  risks  associated  with  making  decisions  about  future  conditions  and  performance. 
Economic  analysis  is  presented  as  a  FEA. 


Best  Business  Practices  -  Benchmarking  proposed  process  improvements 
against  recognized  industry  leaders  is  the  technique  used  to  ensure  the  proposed 
improvements  are  up  to  par  with  the  best  alternatives  available. 
b.  FPl  Methodology 

The  functional  process  improvement  methodology  consists  of  these  steps: 

define,  analyze,  evaluate,  plan,  approve,  and  execute.  Each  of  the  steps  integrates  the 

underlying  principles  to  cover  the  entire  BPR  project  from  start  to  finish. 

Define  -  During  this  phase,  a  framework  is  established  by  defining  baselines, 
objectives,  and  strategies  for  the  process.  Activity  and  data  modeling  begin  in 
preparation  for  the  analysis  phase  from  which  to  begin  process  improvement. 

Analyze  -  This  phase  proposes  the  improved  process  alternatives.  The  As-Is 
process  model  is  analyzed  to  examine  all  processes  that  make  the  current  process 
more  effective  and  efficient.  ABC  data  is  gathered  and  modeled  for  each  activity  of 
the  process  decomposition. 

Evaluate  -  Alternatives  are  compared  against  the  baseline  processes  in  terms  of 
both  function  and  cost. 

Plan  -  A  migration  plan  is  developed  for  each  of  the  contending  improvement 
alternatives.  Tne  plan  should  be  comprehensive  and  cover  the  impact  on  costs, 
benefits,  risk,  and  the  effect  on  the  organizational  structure. 

Approve  -  Pertinent  data  from  the  definition,  analysis,  evaluation,  and  planning 
phases  are  assembled  for  presentation  of  each  of  the  improvement  alternatives  to 
the  highest  level  executive  decision  makers.  This  presentation  is  in  the  form  a 
Functional  Economic  Analysis  (FEA).  A  FEA  is  similar  to  a  traditional  economic 
analysis.  Both  evaluate  the  economic  feasibility  of  a  project  using  classic  economic 
analysis  techniques.  The  primary  difference  between  them  is  scope.  While  an 
economic  analysis  usually  covers  a  single  initiative  an  FEA  covers  the  life-cycle 
aspects  and  the  overall  effect  of  the  intended  change  on  the  entire  organization. 

Execute  -  Once  approved,  the  new  system  is  implemented  in  accordance  with  a 
DoD-wide  technical  integration  and  migration  strategy. 
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C.  SELECTION  CRITERIA 


The  selection  of  a  reengineering  methodology  is  based  on  perceived  conditions  of 
the  business  environment  and  often  depends  on  the  degree  of  interest  by  senior 
management  and  the  amount  of  risk  the  organization  is  willing  to  take  toward 
implementing  redesign  efforts.  Understanding  the  business  environment  and  the 
organization  will  aid  the  reengineering  team  m  the  selection  of  a  methodology.  Before 
selecting  a  methodology,  the  organization  and  analyst  must  consider  reengineering 
categories,  reengineering  ideals,  reengineering  principles,  and  reengineering  roles. 

1.  Reengineering  Categories 

Reengineering  methods  can  be  grouped  into  three  categories:  crisis,  goal  oriented 
and  life-cycle.  (Koulopoulos,  1995) 

Crisis  reengineering  is  a  response  to  pressures,  internal  or  external,  which 
necessitate  a  change  to  current  business  operations.  This  type  of  redesign  is  less  likely  to 
follow  a  formal  methodology.  High  level  sponsorship  within  the  organization  is  not 
required  because  change  must  be  effected  regardless  of  the  method.  Crisis  reengineering 
carries  a  high  degree  cf  risk  since  it  is  often  unplanned. 

Goal  oriented  reengineering  seeks  to  substantially  change  the  fundamental 
business  objectives.  This  strategy  radically  transforms  the  organizational  processes  by 
disregarding  all  present  processes  and  designs  how  the  company  will  function  in  the 
future.  This  method  requires  high  level  sponsorship  due  to  the  inherent  risk  of  eliminating 
familiar  processes  and  implementing  futuristic  procedures. 


Life-cycle  reengineering  is  strategic  and  continuous.  Incremental  changes  are 
made  constantly  to  alter  the  business  direction.  The  redesign  efifort  establishes  a  baseline 
assessment  of  how  business  is  conducted.  Managers  then  use  metrics  to  establish  value  for 
each  task  and  examine  alternatives  that  will  improve  the  processes.  Improvements,  radical 
or  conservative,  to  current  processes  are  made  where  necessary.  This  category  of 
reengineering  requires  a  high-level  champion  to  provide  continuity  and  ensure  adequate 
program  funding.  Life-cycle  reengineering  is  considered  the  safest  for  organizations 
without  the  resources  or  the  capacity  to  assume  the  higher  levels  of  risk  inherent  in  the 
other  categories. 

2.  Reengineering  Ideals 

Hammer  and  Champy  list  four  themes  that  are  preeminent  in  successful 
reengineering  efforts  (Hammer  and  Champy,  1993):  process  orientation,  ambition,  rule¬ 
breaking,  and  creative  use  of  information  technology.  All  four  reengineering  ideals  have 
application  to  the  MCi  modernization  project.  However,  due  to  cultural  and  budgetary 
constraints,  reengineering  at  MCI  was  narrowly  focused  within  the  Student  Services  and 
Information  Systems  Departments,  the  primary  creator  and  administrator  of  the  data. 

Process  Orientation  -  Organizational  perspective  is  influenced  by  the  management 
theory  in  vogue.  The  industrial  age  focused  on  task  organization  and  work  simplification 
in  an  assembly  line.  The  information  age  centered  on  gathering  and  distributing 
information.  The  current  trend  in  “down-sizing”  or  “right- sizing”  leads  to  a  perspective 
focusing  on  processes  and  process  improvement. 
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Task-oriented  jobs  in  today’s  world  of  customers,  competition,  and  change 
are  obsolete.  Instead,  companies  must  organize  work  around  process.  To 
achieve  significant  productivity  and  quality  improvement,  an  entire  process 
must  be  analyzed,  not  just  the  work  steps  within  a  department  of  an 
organization.  (Hammer  and  Champy,  1993) 

Ambition  -  AU  business  processes  within  an  organization  must  be  considered 
candidates  for  reengineering.  Reengineering  teams  must  be  ambitious,  seeking  innovative 
ways  to  improve  all  business  processes.  No  area  should  be  protected  from  this  scrutiny.  As 
noted,  only  one  third  of  the  whole  business  would  be  considered  for  reengineering  as  part 
of  this  modernization  project. 

Rule-breaking  -  Business  rules  are  efforts  by  an  organization  to  standardize 
operating  procedures.  Reengineering  teams  should  consider  new  ways  to  significantly 
improve  productivity  without  allowing  existing  rules  to  limit  their  consideration  of 
alternatives.  This  requires  a  commitment  by  management  to  sever  their  reliance  on  the 
comfort  of  established  procedures.  Considerable  effort  by  MCI  was  put  into  eliminating  or 
streamlining  the  business  rules  and  regulations  attached  to  student’s  course  enrollment. 
This  reduction  in  business  rules  simplified  prototype  coding  and  will  simplify 
implementation  coding  and  code  maintenance  in  the  future. 

Creative  use  of  information  technology  -  Information  technology  (IT)  and  its  rapid 
advances  play  a  significant  role  in  BPR.  Thomas  H.  Davenport  identifies  nine  areas  where 
BPR  can  benefit  from  IT  (Davenport,  1993): 

1 .  Automation  -  IT  can  automate  tasks  reducing  redundancy  of  data  entry 
improving  quality,  integrity  and  speed. 

2.  Information  -  Electronic  transfer  of  information  and  documents  via 
telecommunication  systems  or  networks  decreases  process  completion  time 
and  facilitates  enhanced  work  coordination. 
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3.  Sequence  -  IT,  using  databases  and  groupware,  allows  parallel  work 
accomplishment,  improving  the  sequencing  of  tasks  and  decreasing  overall 
business  cycle  time. 

4.  Tracking  -  IT  enables  the  close  monitoring  of  process  objects  and  their 
completion  status. 

5.  Analysis  ■  The  data  manipulation,  storage  and  presentation  capabilities  of  IT 
allow  for  the  critical  analysis  of  processes  and  their  supporting  information. 

6.  Geography  -  Telecommunications  networks  allow  the  sharing  and  transfer  of 
information  between  geographically  dispersed  organizations. 

7.  Integration  -  Database  and  groupware  technologies  allow  multiple  personnel  to 
work  together  on  a  single  project. 

8.  Intellect  -  IT,  such  as  expert  systems,  allow  the  capture  and  preservation  of 
corporate  knowledge  and  procedures. 

9.  Disintermediation  -  Electronic  data  interchange  decreases  the  requirement  for 
person-to-person  interactions  and  reduces  the  number  of  people  involved  in  a 
process. 

3.  Reengineering  Principles 

Reengineering  principles  represent  the  best  reengineering  practices  collected  from 
the  industry  and  distil  'ed  to  their  very  essence.  Principles  are  not  limited  to  manual  and 
automated  processes,  but  may  also  be  applied  to  the  cultural  aspect  of  reengineering. 

Process  Principles  -  In  any  organization,  there  will  be  manual  and  automated 
processes  subject  to  improvement.  These  principles  are  general  and  can  guide  the 
reengineering  team  (Hammer  and  Champy,  1993); 

•  Combine  several  jobs  into  one  to  involve  fewer  people  in  the  completion  of  a 
process. 

•  Let  the  worker  make  decisions. 

•  Perform  the  steps  of  a  process  in  a  natural  order. 
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•  Designate  a  person  who  will  be  responsible  for  controlling  and  improving  each 
process. 

•  Create  multiple  versions  of  a  process.  Each  version  should  be  dependent  upon 
a  particular  outcome  of  a  decision  made  by  the  person  performing  the  task. 

•  Perform  work  where  it  makes  the  most  sense. 

•  Reduce  checks  and  controls  on  work.  Only  perform  tasks  that  add  value  to  the 
overall  process. 

•  Provide  a  single  point  of  contact  to  business  customers. 

Russ  Linden  delineates  these  additional  principles  (Linden,  1993): 

•  Substitute  parallel  for  sequential  processes  to  decrease  business  cycle  time. 

•  Capture  information  once,  at  the  soiu’ce. 

•  Bring  “downstream”  information  “upstream”  so  that  all  required  information 
for  the  entire  process  is  gathered  and  entered  into  the  system  at  the  start.  This 
will  decrease  data  gathering  and  communication  times. 

•  Ensure  a  continuous  flow  of  value-adding  activities.  Get  rid  of  tasks  that  do 
not  produce  something  of  value  to  the  customer. 

•  Organize  around  outcomes,  not  functions.  Ensure  there  is  an  important 
business  reason  for  conducting  a  process  or  task. 

•  Redesign  first,  then  automate.  Do  not  automate  first  and  simply  speed  up  a 
faulty  procedure. 

•  Know  why  a  piece  of  paper  enters  the  system.  Substitute  technological 
interfaces  where  face-to-face  interactions  are  not  required. 

Cultural  Principles  -  Effective  application  of  these  principles  during  the 
reengineering  process  will  result  in  the  transformation  of  numerous  aspects  of  the 
organization  (Hammer  and  Champy,  1993): 

•  Jobs  change  from  simple  tasks  to  multidimensional  work. 

•  Organizational  stractures  change  from  hierarchical  to  flat. 
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•  Managers  change  from  supervisors  to  coaches,  shifting  emphasis  from 
oversight  and  control  to  facilitator,  enabler  and  educator. 

•  Executives  change  from  scorekeepers  to  leaders. 

•  Values  change  form  protective  to  productive. 

•  People’s  roles  change  from  controlled  to  empowered. 

•  Job  preparation  changes  from  training  to  education. 

•  Focus  of  performance  measures  and  compensation  shifts  from  activity  to 
results. 

•  Advancement  criteria  change  from  performance  to  ability. 

4.  Reengineering  Roles 

Finally,  the  organization  itself  determines  the  outcome  of  any  reengineering  effort. 

A  BPR  consultant  may  be  used  to  advise  the  organization  on  how  to  accomplish  a 

reengineering  project  but  it  is  the  personnel  within  the  organization  who  actually 

reengineer  the  business  processes.  Employees  know  and  understand  the  business  and 

these  personnel  fiU  key  roles  during  the  redesign  project.  (Hammer  and  Champy,  1993) 

Leader  -  The  leader  is  an  executive  level  manager  with  oversight  responsibility. 

The  leader  must  be  able  to  influence  reluctant  employees  to  embrace  the  change 
program.  The  leader  is  the  steward,  creating  the  corporate  vision  while  ensuring 
managerial  and  financial  continuity. 

Steering  comiuittee  -  The  steering  committee  is  a  group  of  senior  managers  who 
define  the  reengineering  strategy,  determine  project  priority,  allocate  resources  and 
assist  the  reengineering  teams  problem  resolution. 

Reengineerini{  czar  -  The  reengineering  czar  is  the  organizational  expert  on 
reengineering  procedures  and  tools  and  must  be  able  to  oversee  the  project  from 
beginning  to  end.  The  czar  must  support  each  process  owner  and  the  reengineering 
team  as  well  as  coordinate  all  reengineering  activities.  The  czar  is  the  technical 
interface  between  the  reengineering  team  members  and  the  leader.  (Hammer  and 
Champy,  1993) 
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Process  owner  -  The  process  owner  is  a  senior  leader  responsible  for  the  effective 
and  efficient  function  of  a  particular  business  process.  The  owner  provides  the 
reengineering  team  with  process  information  during  the  change  effort  and  becomes 
responsible  for  its  implementation  and  continued  optimization. 

External  consultant  -  The  use  of  an  external  consultant  during  a  reengineering  is 
often  recommended  for  several  reasons.  It  may  be  difficult  for  managers  inside  the 
enterprise  to  take  a  detached  view  point.  A  skilled  external  consultant  can  often 
clearly  see  and  diagnose  problems  in  an  organization  that  would  go  unnoticed  by  a 
manager  busy  with  day  to  day  operations.  Consultants  are  also  useful  as  experts  in 
reengineering  methodology  application,  protot3^e  development,  data  and  process 
modeling,  critical  success  factor  analysis,  and  other  aspects  of  reengineering  that 
organic  organizational  mangers  may  not  possess.  Not  only  is  it  important  for  a 
consultant  to  have  technological  expertise  but  they  should  also  exhibit  the  personal 
relationship  skills  necessary  for  them  to  integrate  with  top  management  and  the 
reengineering  team.  Together  they  will  accomplish  the  reengineering. 

The  actual  reengineering  process  is  performed  by  the  reengineering  team.  The 

team  should  be  comprised  of  personnel  from  various  functional  areas,  especially  one 

experienced  in  current  information  technology  advances.  There  should  be  members  from 

outside  the  process  under  review  to  provide  objectivity  and  interface  awareness.  Process 

analysis,  modeling,  and  redesign  are  time  consuming  efforts  and  should  be  done  as  quickly 

as  possible  to  avoid  “paralysis  by  analysis.”  The  team  members  should  be  assigned  to  the 

project  on  a  full-time  basis,  but  not  less  than  75%  commitment  level  is  required.  (Hammer 

and  Champy,  1993) 

D.  BPR  TECHNIQUE  COMPARISON 

AU  of  the  surveyed  methodologies  are  similar  in  composition,  but  differ  in 

sequence  and  level  of  detail  during  execution.  Figure  6  places  the  surveyed  methodologies 
on  the  BPR  spectrum  introduced  earlier  in  the  chapter.  Each  of  the  methodologies  has 
individual  merits  but  there  is  not  one  methodology  perfectly  suited  for  every  situation.  For 
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Figure  6.  BPR  Spectrum  with  Selected  Methodologies  in  Place. 


comparison,  Table  1  summarizes  the  main  stages  of  each  methodology.  Each  has 
strengths,  weaknesses,  and  other  characteristics  that  are  worthy  of  analysis  before 
selecting  the  most  appropriate  methodology  for  the  MCI  modernization  project. 

The  common  thread  running  through  all  of  the  methodologies  is  that  each  of  them 
accomplishes  the  basic  steps  of  traditional  system  development  stages:  planning,  analysis, 
external  design,  internal  design,  and  construction.  The  difference  in  the  methodologies  is 
the  degree  of  detail  they  prescribe.  Table  2  compares  the  methodologies  and  serves  to 
highlight  the  similarities  and  differences  between  them. 

The  methodologies  can  be  grouped  into  two  categories  of  reengineering:  radical 
and  incremental.  Radical  reengineering  “. .  .means  disregarding  all  existing  stmctures  and 
procedures  and  inventing  completely  new  ways  of  accomplishing  work  (Hammer  and 
Champy,  1993).  Incremental  reengineering,  considered  by  Hammer  and  Champy  to  not 
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even  qualify  as  “reengineering,”  is  based  on  the  total  quality  approach  introduced  by 
Demming  in  the  195()s.  Incremental  methodologies  analyze  existing  processes  and  seek  to 
improve  productivity  with  more  conventional,  less  radical  changes  to  organizational 
structure  and  application  of  information  technology.  Both  radical  and  incremental 
reengineering  methodologies  prescribe  process  improvement  but  differ  in  the  scope  of 
their  methods. 

The  methodologies  of  Hammer  and  Champy,  and  Davenport  both  fall  into  the 
radical  methodology  category.  The  methodology  of  Hammer  and  Champy  is  the  most 
radical  and  the  least  detailed.  Hammer  and  Champy  strive  for  dramatic  improvement  and 


70 


“dramatic  improvement  demands  blowing  up  the  old  and  replacing  it  with  something  new” 
(Hammer  and  Champy,  1993). 

While  Hammer  and  Champy  fail  to  provide  techniques  that  reengineering 
practitioners  might  use  to  accomplish  the  task,  their  methodology  has  been  distilled  into 
the  principle  pillars  that  all  other  reengineering  methodologies  are  built  on.  Hammer  and 
Champy’ s  intended  audience  is  the  chief  executive  level  and  is  full  of  motivating  rhetoric 
and  successful  examples  from  the  business  world.  At  the  CEO  level,  detailed  knowledge 
of  techniques  are  not  necessary.  One  of  Hammer  and  Champy ’s  reengineering  principles  is 
that  reengineering  projects  often  fail  due  to  lack  of  top  management  support  Hammer  and 
Champy  serve  to  educate  and  motivate,  top  executives  empowering  them  to  ask  questions 
and  champion  their  o  vn  reengineering  cause.  The  importance  of  IT  application  into  the  re¬ 
invented  corporation  t  nd  reengineering  team  is  also  emphasized. 

Davenport  also  advocates  IT  application  and  provides  more  detail  than  Hammer 
and  Champy  but  not  enough  for  a  reengineering  team  to  rely  on  for  complete 
reengineering.  Like  Hammer  and  Champy,  Davenport’  process  innovation  expects 
reengineering  to  net  substantial  increases  in  productivity  and  profit  by  starting  with  a 
“clean  slate”  and  effecting  a  one-time,  top-down,  broadly  cross-functional  fundamental 
change  to  the  way  the  organization  conducts  business  (Davenport,  1993).  Davenport 
suggests  detailed  techfiiques  to  be  used  for  analyzing  business  environment,  identifying 
candidate  processes  for  innovation,  gathering  performance  objectives,  and  applying  IT 
solutions.  Davenport's  methodology  briefly  mentions  the  role  of  top  management  during 
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reengineering  and  list  industry  success  stories  but  does  not  elaborate  on  techniques  to 
foster  reengineering  leadership  or  organizational  reengineering  roles. 

The  risk  of  failure  for  such  radical  and  sweeping  changes  during  a  short  time  to  an 
organization  is  much  f?igher  than  the  less  radical,  total  quality  based  incremental  process 
improvement  methodologies:  business  process  improvement,  and  functional  process 
improvement.  Both  of  these  methodologies  are  rich  in  practical  techniques  that  can  be 
readily  applied  by  reengineering  practitioners. 

Harrington’s  methodology  offers  comprehensive  coverage  from  planning  to 
implementation.  He  furnishes  guidance  on  how  to  organize  the  organization,  select  teams, 
collect  and  analyze  data,  reengineer  the  process,  and  continue  monitoring  the  improved 
process  after  implementation.  Harrington  emphasizes  the  importance  of  training  the 
reengineering  team  and  executive  leaders  prior  to  beginning  the  project  to  reduce  the  risk 
of  failure.  Specific  techniques  are  augmented  by  examples  of  anal3^ical  methods  (e.g., 
graphs,  charts,  matrices,  etc.)  to  assist  the  practitioner  with  decision  making  throughout 
the  process.  It  is  implied  that  these  tools  could  be  implemented  with  computer  software 
but  Harrington  does  not  specifically  address  the  use  of  any  CASE  tools. 

The  last  methodology  surveyed,  functional  process  improvement  relies  on  CASE 
tools  for  smooth  operation.  The  use  of  CASE  tools  that  model  processes  in  IDEFO,  linked 
with  ABC  analyzing  software  are  mandated  as  is  software  specifically  developed  to 
prepare  a  FEA. 

In  typical  Department  of  Defense  fashion,  the  functional  process  improvement 
model  with  its  25  steps  prescribing  stiU  more  detailed  and  specific  tasks  could  be  labeled 
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the  most  comprehensive  methodology.  Like  BPI,  FPI  offers  comprehensive  coverage  from 
planning  to  implementation.  Rexibility  is  limited,  however,  by  the  hierarchical  constraints 
inherent  in  government  bureaucracy.  For  example,  m  planning  tasks  include  briefing  the 
upper  echelon  about  reengineering  theory,  principles,  risks,  and  benefits  but  do  not 
mention  reengineering  team  composition  or  reengineering  leadership  roles.  FPI  presumes 
that  the  innate  hierarchy  will  suffice.  FPI  data  gathering  and  analysis  techniques  focus  on 
activity  based  cost  accounting  principles  and  culminates  with  the  presentation  of  the  FEA 
to  the  top  level  of  the  aierarchy.  Once  the  ultimate  decision  as  to  which  alternative  to 
choose  is  made,  the  innate  hierarchy  again  is  presumed  to  oversee  the  execution  stage. 

This  methodology  appears  to  be  driven  by  the  process  and  all  reengineering  decisions 
made  exclusively  in  terms  of  lifecycle  costs  with  inadequate  attention  to  implementation 
and  monitoring.  Although  the  methodology  is  inflexible,  the  concept  is  sound  and  is  well 
supported  in  terms  of  software  support  and  training. 

E.  REENGINEERING  METHODOLOGY  SELECTION 

Central  to  the  success  of  the  modernization  project  is  selection  of  a  suitable  BPR 
methodology.  Of  the  many  methodologies  available  foiu  candidates  were  evaluated.  When 
assessing  a  methodol>>gy’s  fit  to  the  MCI  modernization  project,  each  of  the  BPR 
methodology  selectior.  criteria,  discussed  in  the  second  section  of  this  chapter,  was 
considered  in  the  business  environment  context  at  MCI. 

1.  Reengineering  Methodology  Characteristics 

Before  selecting  the  reengineering  methodology  best  suited  for  the  particular 
business  environment  it  is  useful  to  specify  criteria  with  which  the  reengineering  team  can 


compare  competing  methodologies.  The  DoD  Manual  for  BPR  identifies  the  following 
characteristics  of  an  effective  methodology  for  change  management  (DoDInst  8020. 1-M, 
1993): 


Completeness  -  The  methodology  must  provide  steps  that  direct  a  business  process 
improvement  procedure  from  establishment  to  implementation. 

Applicability  -  The  methodology  must  be  able  to  be  used  on  any  process  of  the 
business. 

Friendliness  -  The  procedure  must  be  easy  for  all  personnel,  including  non¬ 
technical  workers  and  managers,  to  learn  and  understand. 

Consistency  -  It  must  be  the  only  methods  used  to  conduct  reengineering  within 
the  organization.  This  will  allow  in-house  reengineering  expertise  to  be  developed. 

Supportable  -  The  reengineering  procedure  must  include  detailed  documentation, 
training  courses  and  project  management  tools. 

Successful  -  The  methodology  should  have  a  record  of  success  and  these  cases 
should  be  available  to  guide  the  actions  of  the  reengineering  team. 

Documentable  -  The  procedure  must  produce  process  documentation  as  it  is  used. 

Enabled  by  Tools  -  The  method  must  be  supported  by  automated  tools  that  help  to 
ease  the  reengineering  workload  and  enable  process  documentation  and 
measurement. 

2.  BPR  Technique  Selection  for  MCI  Modernization  Project 

As  initial  information  was  gathered  about  the  current  information  system  and 
business  process  at  MCI,  research  was  initiated  into  the  most  appropriate  business  process 
reengineering  methodology,  modeling  technique,  and  supporting  CASE  tool.  After 
considering  all  of  the  factors,  there  was  no  one  single  BPR  methodology  that  exactly  fit 
the  MCI  situation  at  face  value.  Elements  of  each  were  used  in  the  end  and  will  be 
discussed  in  detail  in  Chapter  VII. 
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The  methodologies  of  Hammer  and  Champy,  and  Davenport  were  both  ruled  out 
as  the  business  culture  at  MCI  would  not  support  sweeping  changes  to  their  current 
business  process.  Although  Hammer  and  Champy  do  not  offer  specific  techniques,  their 
reengineering  principles  and  ideals  are  cmcial  to  successful  reengineering.  Davenport 
provided  sound  guidance  at  the  strategic  vision  level,  establishing  a  need  for 
reengineering,  and  determining  where  in  the  organization  to  look,  but  lacked  techniques 
for  conducting  the  reengineering. 

In  contrast,  DoD’s  functional  process  improvement  provided  too  much  detail.  It  is 
not  necessary  to  conduct  all  of  the  FPI  tasks  to  successfully  accomplish  organizational 
reengineering.  FPI  was  not  selected  due  to  the  distinct  lack  of  accurate  cost  data  available 
at  MCI  necessary  to  drive  the  ABC  cost  models. 

The  authors  fe  t  that  Harrington’s  business  process  improvement  methodology, 
based  on  continuous  process  improvement  and  offering  comprehensive  and  detailed 
techniques,  provided  the  best  fit  for  MCI  modernization.  Combining  Harrington’s  BPR 
methodology  with  Martin’s  information  engineering  offers  a  strong  overall  methodology 
for  analyzing  MCI  at  the  enterprise  level.  Additionally,  the  integrated  philosophy  espoused 
by  information  engineering  offered  more  flexibility  and  potential  for  application  to  the 
remaining  business  processes  at  MCI  not  included  as  part  of  this  research. 
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V.  TECHNIQUES  AND  TOOLS 

This  chapter  discusses  in  greater  detail  some  of  the  techniques  and  tools  used 
during  the  analysis  of  previous  chapters.  The  first  section  discusses  process  modeling, 
functional  decomposition,  and  IDEFO  modeling  methodology.  The  second  section 
discusses  data  flow  diagranuning  and  its  relevance  to  the  business  system  design  level  of 
the  information  engineering  methodology.  The  final  section  discusses  CASE  tool 
evaluation  and  selection  for  the  MCI  modernization  project. 

A.  ACTIVITY  MODELING 

There  are  many  different  modeling  and  diagramming  techniques  in  use  for  process 
modeling.  Techniques  have  been  borrowed  from  finance,  software  or  systems  engineering, 
and  product  engineering.  Examples  of  modeling  techniques  include:  entity-relationships 
(ER),  structure  charts,  flow  charts,  data  flow  diagrams,  and  IDEE  modeling.  Many  of  the 
techniques  are  variations  of  one  another  and  may  share  semantic  structures  but  vary  in 
their  graphic  presentation  to  convey  different  aspects  of  the  organization  to  different 
audiences.  For  instance,  a  business  may  be  modeled  with  an  entity-relationship  diagram  for 
the  database  designer  while  the  same  business  may  be  presented  to  the  programmer  as  a 
series  of  data  flow  diagrams.  Different  views  of  the  business  require  different  modeling 
techniques. 

1.  Process  Modeling  and  BPR 

The  main  objective  of  business  process  reengineering  is  to  transform  an 
organization  around  the  key  processes  performed  by  the  business  to  improve  productivity 
and  efficiency.  Since  BPR  was  popularized  in  the  early  1990s  by  Michael  Hammer,  many 


77 


similar  but  competing  BPR  methodologies  have  been  published.  Although  they  vary  in 
scope  and  complexity,  the  common  thread  among  them  is  the  use  models  to  represent  the 
interdependent  and  often  complex  relationships  that  exist  between  the  elements  of  a 
modem  organization  (i.e.,  business  rules,  processes,  stakeholders,  inputs  and  ou^uts). 
Effective  BPR  can  not  be  conducted  without  first  understanding  the  organization.  Models 
enable  understanding  by  structuring  business  information  in  a  way  that  individual 
components  can  be  visualized  and  interdependencies  can  be  analyzed. 

Models  are  more  than  diagrams.  While  the  diagram  of  a  model  may  depict  a 
process  as  a  series  of  activities  with  inputs  and  outputs,  many  details  about  the  process 
need  to  be  defined.  Information  such  as  the  activity’s  name,  definition,  owner,  inputs, 
outputs,  etc.  are  stored  in  a  central  repository  known  as  a  data  dictionary  or  data 
encyclopedia.  The  data  contained  in  a  data  encyclopedia  is  also  known  as  metadata.  This 
collection  of  metadata  ensures  consistency  throughout  the  modeling  process. 

2.  Process  Modeling  Technique 

A  process  or  activity  model  is  a  tool  used  by  an  analyst  to  understand  a  business’ 
current  environment  and  provides  a  framework  with  which  a  business  may  be 
systematically  dissected  and  analyzed  with  an  eye  to  improve  the  business  process  in  some 
way.  “A  process. .  .is  a  specific  ordering  of  work  activities  across  time  and  place,  with  a 
beginning  ,  an  end,  and  clearly  identified  inputs  and  outputs:  a  structure  for  action” 
(Davenport,  1993).  These  activities  are  the  building  blocks  of  process  models.  The 
process  model  makes  business  area  analysis  possible. 


78 


A  completed  process  model  graphically  depicts  the  individual  steps,  information, 
and  resources  needed  to  perform  a  business  process  as  well  as  how  sub-processes  may  be 
interdependent.  Additionally,  activity  modeling  is  an  important  step  in  validating 
information  requirements  within  an  organization,  because  the  activity  model  shows  the 
relationship  between  an  activity  and  the  information  that  it  uses  or  produces.  This  level  of 
detail  is  necessary  to  conduct  effective  redesign  analysis. 

A  process  or  activity  model  is  used  to  describe  business  activities  and  their 
relationships.  It  is  hierarchical  and  starts  with  a  high-level  view  of  the  process.  The  model 
then  breaks  a  process  into  sub-processes.  Sub-processes  may  also  be  divided  into  sub-sub- 
processes  and  so  on  providing  increasing  levels  of  detail.  This  technique  is  known  as 
functional  decomposifion.  For  this  reason,  individual  activity  model  diagrams  are  often 
known  as  decomposition  diagrams.  Functional  decomposition  is  further  explained  in  the 
next  subsection. 

The  IDEF  series  of  modeling  methodologies  offer  easily  interpreted  diagrams,  data 
sharing  capabilities  between  data  and  process  models,  and  a  standardized  format  well 
suited  for  computer  aided  analysis.  IDEFO  was  mandated  by  MCI  for  process  modeling, 
and  IDEFIX  was  mandated  for  data  modeling.  IDEF  modeling  techniques  are  the 
modeling  standard  for  agencies  within  the  Department  of  Defense. 

IDEFO  is  one  of  the  most  useful  process  modeling  techniques  and  was  used  for  this 
analysis  for  two  reasons.  First,  IDEFO  is  the  modeling  technique  mandated  by  the 
Department  of  Defense  (DoD)  business  process  reengineering  initiative,  an  agenda  item  of 
the  Corporate  Information  Management  (CIM)  program.  CIM  was  initiated  in  the  early 
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1 990s  when  Paul  Strassmann  was  the  director  of  the  Defense  Information  Systems  Agency 
(DISA).  CM’s  goals  were  to  maintain  DoD  mission  capabilities  despite  downsizing  and 
budget  reductions  by  implementing  improved  business  processes  which:  (1)  are  enabled 
by  technology,  (2)  substantially  increase  productivity,  (3)  decrease  cost,  and  (4)  do  not 
sacrifice  quality.  Secondly,  the  IDEFO  modeling  technique  has  unique  and  powerful 
features  not  found  in  any  other  single  process  modeling  technique.  Figure  7  is  an  example 
of  a  decomposition  diagram  using  the  IDEFO  modeling  technique. 


Figure  7.  IDEFO  Activity  Diagram. 


3.  Functional  Decomposition 

The  process  model  is  developed  using  a  technique  known  functional 


decomposition.  Functional  decomposition  is  a  method  of  moving  from  the  functional 
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areas  at  the  enterprise  level  through  the  business  areas  and  finally  exploding  the  business 
processes  to  their  primitive  level.  Figure  8  graphically  depicts  functional  decomposition. 
The  figure  is  useful  in  helping  the  reader  to  distinguish  between  several  related  terms. 

Functional  areas  are  defined  at  the  enterprise  level  and  exist  to  define  the  business 
functions  of  the  organization  as  a  whole.  Functional  areas  are  the  very  essence  of  the 
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Figure  8.  Functional  Decomposition.  After  Martin,  1992. 
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business  and  refer  to  major  areas  of  activity,  but  do  not  include  sufficient  granularity  for  a 
detailed  analysis.  For  example,  Avhen  developing  the  MCI  enterprise  model,  seven 
functional  areas  were  identified  that  represent  the  business  activity  of  MCI  (described  in 
Chapter  VIj.  These  include  headquarters  support,  course  management,  course 
development,  student  servicing,  information  systems  management,  warehouse  and 
distribution,  and  unit  interaction.  These  functional  areas  define  the  business  of  MCI  but  do 
not  provide  enough  detail  to  describe  the  detailed  processes  performed  by  MCI  personnel. 
Functional  areas  are  subdivided  into  business  functions. 

Business  functions  are  a  collection  of  activities  which  together  support  a  functional 
area  by  furthering  the  mission  of  the  organization.  A  business  function  is  continuous  and 
ongoing  and  is  concerned  with  what  is  to  be  done  but  not  how.  For  example,  four  business 
functions  support  the  functional  area  student  servicing,  identified  in  the  MCI  enterprise 
business  model.  These  business  functions  include  customer  servicing,  student  activity 
transactions,  grading,  and  registrar  servicing.  Like  the  functional  areas,  these  business 
functions  lack  sufficient  detail  for  analysis.  Business  functions  are  subdivided  into  business 
processes.  (Martin,  1990B) 

A  business  process  is  a  specific  act  with  a  definable  beginning  and  end,  identifiable 
inputs  and  outputs,  and  is  performed  repeatedly.  It  is  at  this  level  that  sufficient  detail  is 
added  to  the  model  to  allow  for  analysis  and  reengineering.  Complex  processes  may  be 
further  subdivided  into  simpler  processes  until  a  primitive  level  process  is  reached  when 
any  further  decomposition  would  yield  no  greater  understanding  of  the  process. 
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Enterprise  le'  .1  modeling  tends  to  emphasize  the  terms  functional  area,  business 
function,  and  business  process.  Once  the  business  area  analysis  stage  begins,  functional 
areas  are  known  as  business  areas,  business  functions  are  known  as  functions,  and  business 
processes  become  processes.  The  terms  are  often  used  interchangeably  in  reengineering 
text  books.  The  term  activity  is  a  generic  term  often  substituted  for  a  process  at  any  level 
of  analysis.  The  similarity  of  the  terms  can  be  confusing.  Table  3  maps  the  term  to  the 
information  engineering  stages. 


Enterprise  Analysis 
(Information  Engineering 
Stage  1) 

◄ - ► 

Business  Area  Analysis 
(Information  Engineering 
Stage  2) 

functional  area 

of  the  enterprise  is 
known  as 

business  area 

business  function 

of  the  enterprise  is 
known  as 

function 

business  process 

of  the  enterprise  is 
known  as 

process 

Table  3.  Terminology  Map  Between  the  First  Two  Levels  of  IE. 


4.  Evaluation  of  IDEFO  Technique 

IDEFO  was  developed  in  the  late  1970s  as  a  by-product  of  the  U.S.  Air  Force’s 
Integrated  Computer  Aided  Manufacturing  (ICAM)  Program.  The  Integration  Definition 
for  Information  Modi.ring  (IDEF  for  short)  technique  resulted  in  several  graphical 
modeling  conventio):s,  each  used  for  a  different  purpose.  For  example,  DDEFIX  is  used 
for  data  modeling  anu  IDEFO  is  used  for  functional  modeling.  Although  IDEFO  was 
originally  used  to  document  manufacturing  processes  and  to  show  what  information  and 
resources  were  needed  in  each  step,  it  was  proven  to  be  well  suited  for  modeling  any 
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application  that  uses  information  and  resources.  BDEFO  modeling  has  been  used  in  both 
government  and  private  industry  since  1985  and  has  become  the  DoD  standard  for  process 
modeling. 

An  IDEFO  model  represents  business  activities  from  a  functional  point  of  view. 

The  model  depicts  how  the  activities  interrelate,  the  inputs  used  by  each  activity  during 
activity  execution,  and  the  output  of  each  activity.  The  model  itself  is  hierarchically 
composed  of  decomposition  diagrams  and  the  data  repository  which  contains  the 
definitions  of,  and  relationships  between,  each  of  the  activities,  inputs,  outputs,  controls, 
and  mechanisms.  The  acronym  ICOM  is  used  collectively  to  describe  any  of  the  possible 
information  flows  into  or  out  of  an  activity:  inputs,  controls,  outputs,  or  mechanisms. 

The  IDEFO  activity  modeling  technique  represents  the  business  process  with  four  types  of 
diagrams  in  addition  to  the  metadata  encyclopedia. 

1.  Node  trees  diagrams  graphically  portray  activities  in  a  hierarchical  form. 

2.  A  context  diagram  is  a  single  diagram  that  illustrates  the  highest  level  activity. 

3.  Decomposition  diagrams  represent  the  detailed  sub-processes  of  an  activity. 

4.  FEO  (For  Exposition  Only)  diagrams  are  used  to  focus  attention  on  a 
particular  portion  of  a  node  tree,  context,  or  decomposition  diagram  and  do 
not  have  tc  conform  to  all  of  the  modeling  rules. 

IDEFO  process  models  integrate  smoothly  with  activity  based  costing  techniques 
to  provide  a  powerful  all-encompassing  model  to  accelerate  the  reengineering  process. 
ABC  is  a  powerful  tool  for  measuring  business  performance,  determining  the  business 
process  costs,  and  as  a  means  of  identifying  ineffective  and  inefficient  activities.  Because 
the  IDEFO  activity  model  provides  a  stmctured  approach  detailing  an  activity’s 


information  input  and  output,  the  addition  of  process  cost  details  (e.g.,  the  cost  of  labor, 
materials,  and  overhead)  associated  with  accomplishing  the  task,  the  value  of  each 
individual  task’s  contribution  to  the  whole  can  be  assessed.  Activities  that  are  not  cost 
effective,  or  add  no  value  to  the  business  product,  but  do  incur  costs,  become  early  targets 
for  elimination  when  streamlining  the  business  process. 

5.  IDEFO  Terminology  and  Constructs 

This  section  presents  a  brief  overview  of  IDEFO  terminology,  symbols,  and 
constructs  to  assist  the  reader  in  interpreting  IDEFO  diagrams.  Figure  9  illustrates  the 
IDEF  symbols. 


Input- 


Control 


Mechanism  Call 


Activity 
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>Output 


Figure  9.  IDEFO  Symbols. 


Activity  -  a  function  or  process  that  must  be  accomplished  and  produces  output. 
Activities  are  represented  by  a  box,  are  numbered  hierarchically,  and  are  named 
with  a  verb  phrase  to  describe  what  they  do.  Activities  are  numbered  hierarchically 
with  each  decomposition  retaining  the  parent’s  number  followed  by  a  decimal 
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point  and  its  own  number  beginning  with  one.  (e.g.,  the  parent  activity  numbered 
A-1.2  could  have  two  children  numbered  A-1.2.1  and  A-1.2.2). 

Primitive  Activity  -  an  activity  that  is  not  decomposed  further  (i.e.,  has  no  children 
activities).  In  a  decomposition  diagram,  a  primitive  level  process  is  distinguished 
by  a  small  diagonal  slash,  known  as  a  leaf,  in  the  top  left  corner  of  the  activity  box. 

Context  Diagram  -  the  model  diagram  representing  the  highest  level  activity  or 
process.  It  contains  only  one  activity  box  with  the  model  subject  as  its  name.  It  is 
the  starting  point  for  the  decomposition  of  the  entire  model.  The  context  diagram 
is  numbered  A-0. 

Decomposition  -  a  method  of  moving  from  general  to  specific  through 
decomposition  diagrams  by  separating  activities  into  components. 

Decomposition  Diagram  -  a  diagram  representing  a  more  detailed  look  at  an 
activity.  The  top  level  provides  overview  while  each  succeeding  diagram  provides 
greater  detail  of  the  previous  diagram.  Decomposition  diagrams  are  numbered 
hierarchically  with  each  subsequent  diagram  retaining  the  parent’s  number 
followed  by  a  decimal  point  and  its  own  number  beginning  with  one.  (e.g.,  the 
parent  diagram  numbered  A2  would  have  a  child  diagram  numbered  A2.1) 

Parent  Diagram  -  any  decomposition  diagram  that  contains  an  activity  that  has 
been  decomposed  (i.e.,  has  children  diagrams). 

Child  Diagram  -  any  decomposition  diagram  that  represents  the  details  of  a  parent 
activity. 

Node  Tree  Diagram  -  shows  the  activities  arranged  hierarchically  in  a  tree 
structure. 

Input  (Arrow)  -  represent  data  or  objects  consumed  by  the  activity.  Input  arrows 
always  enter  the  diagram  from  the  left  and  terminate  at  an  activity. 

Output  (Arrow)  -  represent  data  or  objects  produced  by  the  activity.  Output 
arrows  always  exit  an  activity  and  exit  the  diagram  to  the  right. 

Control  (Arrow)  -  represent  data  or  objects  that  specify  conditions  that  must  exist 
for  the  activity  to  work  correctly.  Control  arrows  always  enter  the  diagram  from 
the  top  and  terminate  at  an  activity. 

Mechanism  (Arrow)  -  represent  data  or  objects  that  assist  the  activity  in 
performing  its  task.  Mechanism  arrows  always  enter  the  diagram  from  the  bottom 
and  terminate  at  an  activity. 
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Call  (Arrow)  -  a  type  of  control  arrow  that  calls  on  another  activity.  Call  arrows 
always  exit  an  activity  and  exit  the  diagram  at  the  bottom. 

B.  DATA  FLOW  DIAGRAMS 

Data  flow  diagrams  are  another  representation  of  the  process  model.  Specifically, 
DFDs  are  used  to  depict  the  information  system  model.  Once  the  process  model  has  been 
reengineered,  the  business  system  designer  must  develop  a  prototype.  Input  and  output 
information  depicted  on  the  activity  model  is  too  abstract  to  aid  the  programmer  in 
prototype  development  and  coding.  A  programmer  must  retrieve  the  data  from  the 
database  tables,  manipulate  it  according  to  the  process  model  and  business  rules,  and 
finally,  route  the  output  data  to  another  process  or  database  table.  For  this  reason  even  the 
lowest  level  process  decomposition  diagram  is  of  little  use  to  the  programmer  because  the 
process  model  does  not  indicate  the  precise  source  or  destination  of  the  data.  A  DFD 
maps  the  data  sources  and  sinks  (i.e.,  database  tables)  to  the  data  elements  that  flow  to 
and  from  each  process.  Data  flow  diagrams  serve  as  the  interface  between  the  data 
modeler,  process  developer,  and  GUI/prototype  designer. 

Data  flow  diagrams  start  at  the  highest  level  with  a  context  process  designated  as 
the  context  diagram.  Diagram  level  zero  then  decomposes  the  context  diagram  into  major 
activities.  Decomposition  continues  to  a  level  that  allows  the  programmer  to  map 
individual  data  elements  to  specific  process  activities.  Figure  10  is  an  example  of  a 
primitive  level  DFD  showing  the  information  system  designer  which  data  elements  are 
required  and  from  which  database  table  they  originate. 
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Figure  10.  Primitive  Level  Data  Flow  Diagram. 


1.  Similarities  Between  DFDs  and  Activity  Models 

Because  activity  models  and  data  flow  diagrams  represent  the  same  process  and 
data  elements,  there  are  similarities  between  them.  Properties  that  process  models  and 
DFDs  share  include:  functional  decomposition,  hierarchical  numbering,  and  parenVchild 
relationships. 

Functional  Decomposition  -  The  functional  decomposition  concept  is  the  same.  In 
DFDs  a  context  diagram,  numbered  “0”  forms  the  basis  for  the  system  and  all 
decompositions  stem  from  it. 

Hierarchical  Numbering  -  The  hierarchical  numbering  scheme  for  DFDs  is  similar 
to  that  used  in  the  activity  models.  DFD  process  numbers  are  prefixed  with  a  “P.”  DFD 
data  store  numbers  are  prefixed  with  a  “D.”  DFD  processes  are  numbered  hierarchically 
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with  each  decomposicon  retaining  the  parent’s  number  followed  by  a  decimal  point  and  its 
own  number  beginning  with  one  (e.g.,  the  parent  process  numbered  P-1.2  could  have  two 
children  numbered  P-1.2.1  and  P-1.2.2).  Primitive  level  processes  are  denoted  with  a  “P” 
suffix  (e.g.,  P-2.3.2.1P). 

ParentIChild  Relationships  -  Child  processes  and  data  stores  are  considered  to  be 
part  of  their  parent  and  serve  to  reveal  more  detail.  For  example,  it  is  assumed  that  when 
referring  to  a  parent  data  store  all  information  contained  in  its  children  is  included. 

2.  Data  Flow  Diagram  Symbols 

Although  DFDs  are  a  similar  to  the  process  decomposition  diagrams  of  the  As-Is 
and  To-Be  IDEFO  models  they  use  different  notation.  There  are  three  data  flow 
diagramming  symbol  conventions  in  contemporary  use:  Gane  and  Sarson,  Yourdon  and 
DeMarco,  and  Ward  and  Mellor.  Each  depicts  data  flows  within  a  information  system 
using  different  symbology.  Data  flow  diagrams  for  this  project  are  created  in  the  Gane  and 
Sarson  convention.  DFDs  depict  only  four  symbols:  (1)  external  entity,  (2)  process,  (3) 
data  flow,  and  (4)  data  store.  Figure  1 1  depicts  Gane  and  Sarson  DFD  symbols.  All  DFD 
objects  are  defined  in  the  central  data  repository. 

External  EntitylSource  or  Sink  (not  to  be  confused  with  entity  in  the  data  model 
terminology)  -  a  data  source  from  outside  the  information  system  that  either  sends  data  to 
the  system  or  receives  data  from  the  system.  It  is  not  considered  to  be  part  of  the 
information  system  a’tliough  it  interacts  with  the  system.  Outside  entities  are  labeled  with 
a  noun.  They  may  be  duplicated  on  different  diagrams  and  are  depicted  on  the  diagram  as 
a  double  square  box. 
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Figure  11.  Gane  and  Sarson  Data  Flow  Diagram  Symbols. 


Process  -  represents  an  activity  that  transfers  or  transforms  data  within  the  system. 
Processes  are  labeled  with  a  verb-adjective-noun  and  numbered  hierarchically.  They  may 
'  be  duplicated  on  different  diagrams  and  are  depicted  on  the  diagram  as  a  box  with 
rounded  comers.  The  hierarchical  process  number  is  shown  in  the  top  portion  of  the  box. 

Data  Flow  -  data  that  is  created,  read,  updated,  or  deleted  by  the  system. 
Arrowheads  denote  the  source  and  destination  of  each  piece  of  data.  Data  flows  are 
labeled  with  a  noun.  They  may  be  duplicated  on  different  diagrams  and  are  depicted  on  the 
diagram  as  an  arrow. 

Data  Store  -  may  represent  a  computerized  file,  a  database,  a  manual  store,  or  a 
logical  collection  of  data.  Temporary  files  created  by  processes  within  the  system  are  not 
considered  in  the  data  flow  diagrams.  Data  stores  are  labeled  with  a  noun  and  numbered 
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hierarchically.  They  may  be  duplicated  on  different  diagrams  and  are  depicted  on  the 
diagram  as  a  rectangle. 

3.  Process  Specifications 

Process  specifications  are  a  verbal  description  of  the  process.  Process 
specifications  accompany  DFDs  and  provide  a  concise  summary  of  each  activity.  They  aid 
the  prototype  developer  in  interpreting  the  data  flow  diagrams.  Examples  of  process 
specifications  include:  process  name,  process  number,  data  inputs,  data  outputs, 
structured  English  description  of  the  process  logic. 

C.  CASE  TOOLS 

Information  engineering  is  a  flexible  methodology  supported  by  many  generic 
software  CASE  tools.  Initially,  Texas  Instruments  developed  a  mainframe  based  CASE 
tool  specifically  supporting  Martin’s  planning,  documentation,  modeling,  analysis,  and 
reporting  techniques.  As  information  technology  evolved  from  mainframes  to  networked 
PC  architecture,  a  variety  of  generic  BPR  CASE  tools  supporting  central  data 
repositories,  process  .Tiodeling,  data  modeling,  structured  design,  and  code  generation 
have  been  developed  to  support  the  methodology.  IE  methodology  is  comprehensive, 
covering  all  phases  of  system  the  life  cycle.  The  reader  will  recall  that  the  specific 
techniques  used  in  the  IE  methodology  are  not  specified  and  secondary  to  the  integration 
and  application  of  the  underl5dng  framework.  This  flexibility  allows  IE  methodology  to  be 
tailored  to  achieve  the  best  possible  match  of  situation  to  technique.  For  example,  a 
variety  of  process  modeling  techniques  can  be  used  such  as  DDEFO,  entity-relationships. 
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structure  charts,  or  data  flow  diagrams.  Each  modeling  methodology  is  used  to  show 
different  views  of  the  same  process. 

Many  CASE  tools  have  been  designed  specifically  to  support  business  process 
reengineering,  data,  and  process  modeling.  Choosing  an  appropriate  CASE  tool  to  assist 
the  analyst  early  in  the  reengineering  effort  reduces  the  length  of  time  to  complete  the 
project. 

1.  Selection  Criteria 

CASE  tool  selection  should  be  done  after  a  reengineering  methodology  is  selected. 
Tool  choice  should  be  based  on  its  ability  to  support  aU  aspects  of  the  reengineering 
methodology.  If  one  tool  will  not  satisfy  all  of  the  requirements,  the  ability  for  multiple 
tools  to  share  data  becomes  an  overriding  consideration.  Careful  scrutiny  of  the  advertised 
data  sharing  procediu  es  and  interfaces  is  also  advised  to  enhance  seamless  integration 
between  the  tools.  Regardless  of  the  reengineering  methodology  chosen,  a  CASE  tool 
should  possess  the  foUowing  capabilities. 

•  Capture,  visualize,  and  monitor  end-to-end  processes 

•  Represent  process  mles  and  exceptions 

•  Dynamically  re-plan  and  reschedule  activities 

•  Simulate  discrete  events 

•  Analyze  the  tradeoffs  in  hypothetical  scenarios  of  process  redesign 

•  Proactively  manage  and  leam  fi’om  day-to-day  events 
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2.  CASE  Tool  Evaluation 


There  are  many  CASE  tools  available  to  support  business  process  reengineering. 
The  authors  initially  considered  four  such  tools:  System  Architect/BPR  Professional, 
BPwin®,  Informatior  Engineering  Facility™,  and  TurboBPR. 

Information  Engineering  Facility'^^  (LEF^'^)  was  developed  with  James  Martin  by 
Texas  Instruments  to  support  Martin’s  information  engineering  methodology.  Although, 
lEF™  offered  the  most  comprehensive  support  package  of  the  CASE  tools,  its  use  was 
rejected  outright  because  both  its  own  operation  and  the  code  it  generated  is  based  on 
mainframe  technology. 

TurboBPR  2.5  is  a  Windows-based  business  process  reengineering  support  tool 
developed  for  the  Office  of  the  Secretary  of  Defense  by  SRA  Corporation.  TurboBPR  is 
designed  specifically  to  support  the  DoD  functional  process  improvement  methodology. 
TurboBPR  consists  of  five  modules  to  assist  with  enterprise  level  information  storage, 
strategic  planning,  activity  based  cost  accounting,  and  preparation  of  the  functional 
economic  analysis.  In  spite  of  a  formidable  reporting  feature,  TurboBPR  2.5  was  not  used 
for  this  research  because  it  lacked  integral  data  and  process  modeling  modules. 

The  remaining  two  competitors.  System  Architect/BPR  Professional  (SA/BPR 
Pro),  by  Popkin  Software  &  Systems  Incorporated,  and  BPwin©  (BPwin),  by  Logic 
Works,  Incorporated,  are  windows  based  modeling  and  simulation  software  designed  to 
support  a  variety  of  business  process  reengineering  methodologies  by  documenting 
complex  business  processes.  Both  CASE  tools  offer  comparable  performance  and  share 
common  features: 
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•  A  commor.  data  repository,  ensuring  model  consistency 

•  Structured  analysis  &  design  techniques  for  creation  of  DFDs,  STDs  and 
structure  charts  in  standard  or  real-time  methodologies 

•  Process  modeling  techniques  including  IDEFO 

•  Object  oriented  design  techniques 

•  Forward  and  reverse  engineering  capabilities 

•  Project  documentation  facility  offering  desktop  publishing  features  used  to 
create  reports  and  analyze  data  stored  in  the  central  repository 

•  Additional  features  such  as  common  word  processor  interface,  rules  checks  and 
balancing,  import  and  export  capabilities,  etc. 

The  major  difference  between  SA/BPR  Pro  and  BPwin  is  that  SA/BPR  Pro  has 
data  modeling  capability  and  can  generate  database  schemata  in  a  variety  of  popular 
databases.  BPwin  has  no  data  modeling  capability  of  its  own. 

Both  SA/BPR  Pro  and  BPwin  have  excellent  on-line  tutorial  support.  BPwin’s 
tutorial  was  particularly  relevant  to  this  research  because  IDEFO  modeling  examples  are 
used  to  illustrate  the  tool’s  features.  An  inherent  disadvantage  of  SA/BPR  Pro’s  additional 
features  is  the  required  diversity  of  the  on-line  tutorial.  Despite  comprehensive  coverage, 
the  tutorial  is  more  complex  and  leaves  the  user  with  a  sense  that  BPwin  is  more  intuitive 
and  easier  to  operate.  To  fuUy  exploit  all  of  SA/BPR  Pro’s  many  features,  considerably 
more  time  must  be  devoted  to  learning  to  operate  the  tool. 

SA/BPR  Pro  nas  a  more  versatile  graphics  package  for  developing  data  flow 
diagrams.  BPwin’s  saactured  analysis  and  design  screen  graphics  package  limits  the  user 
to  a  single  8.5  by  1 1  inch  page,  often  resulting  in  cluttered  diagrams.  SA/BPR  Pro  allows 
diagramming  on  multiple  pages. 
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An  attractive  characteristic  of  both  S  A/BPR  Pro  and  BPwin  is  the  advertised  data 
sharing  capability  with  the  competition.  In  theory,  this  feature  would  permit  parallel 
development  of  the  data  and  process  models  using  the  premier  CASE  tool  for  each  and 
allow  maintenance  of  a  virtual  metadata  encyclopedia.  The  choice  of  closely  integrated 
tools  that  allow  data  models  and  process  models  to  share  data  sounds  appealing  and  was 
attempted.  However,  as  parallel  model  development  progressed,  the  authors  discovered 
that  in  order  to  “share”  data  between  models  required  exporting  the  data  into  Microsoft 
Word,  converting  the  file  into  a  comma  delimited  format,  and  finally  importing  it  into  the 
other  model.  As  the  number  of  activities,  arrows,  relationships,  entities,  and  attributes 
continued  to  grow,  this  import/export  routine  became  quite  cumbersome.  Unfortunately, 
this  procedure  was  necessary  even  for  minor  changes  to  maintain  model  consistency. 

S A/BPR  Pro’s  single  data  repository  would  have  eHminated  this  inconvenience. 

A  feature  BPwin  has  that  S  A/BPR  Pro  does  not  have  is  an  advertised  compatibility 
with  a  sibling  data  modeling  product,  ERwin.  ERwin  was  the  CASE  tool  chosen  for  data 
model  development.  Their  common  manufacturer  claimed  seamless  data  sharing  between 
the  two  products  by  building  identical  data  structures  within  the  encyclopedia  of  each  tool. 
However,  as  parallel  model  development  progressed,  it  was  discovered  that  a  similar 
import/export  routine  was  necessary  to  transfer  data  model  information  from  ERwin  into 
BPwin.  This  process  .iid  not  require  the  exported  file  to  be  comma  delimited  before 
import,  but  the  two  data  encyclopedia  stmctiues  were  not  identical.  Initially,  definitions 
generated  and  stored  by  ERwin  could  not  be  imported  into  BPwin.  In  spite  of  this  fault 
process  model  development  was  not  impeded  because  data  element  and  data  table  names 
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were  imported  and  could  be  used.  Deficiencies  in  the  BPwin  data  dictionary  were 
overcome  by  a  software  patch  distributed  by  the  vendor  which  enabled  the  data  dictionary 
file  of  both  tools  to  produce  one  encyclopedia  containing  all  model  information. 

3.  CASE  Tool  Selection 

CASE  tool  selection  for  the  MCI  modernization  project  is  based  on  supportability 
of  the  information  engineering  methodology  and  the  IDEFO  modeling  technique.  In  spite 
of  the  fact  that  Texas  Instraments’  Integrated  Engineering  Facility™  CASE  tool  was 
developed  specifically  to  support  the  IE  methodology,  its  mainframe  theme  made  it 
unsuitable  for  MCI  modernization  use.  TurboBPR2.5,  too,  was  unsuitable  because  it  did 
not  support  process  modeling  with  an  integrated  module.  CASE  tool  contenders  were 
quickly  narrowed  to  System  Architect/BPR  Professional  and  BPwin®.  BPwin®  was 
selected  over  to  System  Architect/BPR  Professional  for  several  reasons. 

•  Advertised  interoperability  with  its  sibling  data  modeling  product,  ERwin®. 
ERwin®  was  the  CASE  tool  selected  for  the  data  modeling  portion  of  the  MCI 
modemizi-iion  project. 

•  Intuitive  functionality  made  BPwin®  easier  to  learn  than  System 
Architect/BPR  Professional. 

•  Economically,  the  BPwin®/ERwin®  combination  was  more  affordable  than 
System  Architect/BPR  Professional. 


96 


VI.  MCI  ENTERPRISE  ANALYSIS 

This  chapter  describes  the  process  modeling  effort  in  support  of  the  MCI 
modernization  project  The  chapter  begins  with  a  detailed  description  of  the  enterprise 
analysis.  It  includes  a  survey  of  the  data  collected  with  an  explanation  of  its  analysis.  The 
chapter  concludes  with  the  presentation  of  the  enterprise  business  model. 

A.  ENTERPRISE  ANALYSIS  OVERVIEW 

An  enterprise  analysis  provides  a  high-level  overview  of  the  information 
requirements  of  an  organization.  The  objective  of  this  effort  defines  an  architectural 
framework  for  future  development  The  framework  consists  of  three  major  components: 
information,  business  system  and  technical  architecture.  The  three  architectures  lay  the 
foundation  from  which  the  organization  can  build  an  information  system  to  manage  its 
information  resources  and  support  its  business  activity.  (Martin,  1990B) 

A  high-level  perspective  provides  a  basis  from  which  detailed  analysis  in 
subsequent  stages  can  be  pursued.  It  serves  as  a  mechanism  to  identify  interdependency 
and  redundancy  of  business  activities  within  the  organization.  The  first  stage  of  Martin’s 
IE  methodology  provides  a  technique  to  identify,  evaluate,  plan  and  manage  the  use  of 
information  to  meet  the  organization’s  information  system  requirements. 

B.  MCI  ENTERPRISE  ANALYSIS 

The  enterprise  analysis  conducted  for  MCI  was  accomplished  in  two  parts.  The 
first  part  identified  the  organizational  units,  locations,  functions  and  data  subjects  for  MCI. 
This  was  a  data  collection  effort  directed  at  defining  the  architectural  framework  of 
development  of  MCI’s  information  system.  The  second  part  focused  on  analyzing  the  data 
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collected  to  document  an  enterprise  overview  of  MCI.  The  documentation  analyzes  the 
relationships  between  organizational  units,  locations,  functions  and  data  subjects,  as 
illustrated  in  Figure  12,  using  charts  and  matrices. 


Figiure  12.  Enterprise  Analysis  Components. 


After  Martin,  1990B. 

C.  roENTIFY  INFORMATION  SYSTEM  REQUIREMENTS 

The  NFS  team  traveled  to  the  Marine  Corps  Institute  in  Washington,  DC  for  the 
MCI  Redesign  kick-off  meeting  held  August  26-29, 1996.  Prior  to  the  meeting,  the  NPS 
team  received  a  read-ahead  package  from  MCI.  The  package  included  a  description  of  the 
existing  organizational  structure,  an  incomplete  business  model  previously  prepared  by' an 
independent  contractor,  an  existing  data  dictionary,  a  task  breakdown  of  Student  Services 
Department,  historical  briefing  packages  and  background  documentation  on  Marine  Corps 
Institute.  Each  department  head  presented  a  brief  that  identified  the  department’s 
organization,  key  personnel,  mission  and  functions.  The  meeting  provided  a  means  to 
observe  the  business  culture  and  political  enviroiunent  of  MCI.  Additional  documentation. 
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such  as  training  manuals,  SOPs,  existing  input  screen  shots,  and  management  reports,  was 
obtained  during  interviews  and  in  response  to  requests  following  the  initial  meeting. 

MCIAIS  is  a  mission-critical  system  to  MCI.  The  Student  Services  Department  is 
the  chief  beneficiary  of  the  information  stored  within  MCIAIS.  This  is  primarily  due  to  the 
lost  functionality  of  various  sub-systems  over  time.  It  was  apparent  that  each  department 
head  was  frustrated  because  the  current  MCIAIS  was  driving  the  way  they  did  business, 
instead  of  enabling  improvements  to  process  efficiency. 

1.  Organization  Structure 

Chapter  II  described  the  organizational  structure  into  which  MCI  fits.  The 
enterprise  analysis  focuses  on  MCFs  reporting  structure.  An  understanding  of  the  MCI  in 
this  context  was  important  to  identify  stakeholders  to  interview  and  provided  a  basis  for 
determining  responsibilities  for  the  activities  of  the  enterprise  (Martin,  1990B). 

The  Director  of  Marine  Corps  Institute  is  also  the  Commanding  Officer  of  Marine 
Barracks,  Washington,  DC.  This  billet  is  staffed  by  a  Marine  Corps  Colonel.  The  position 
as  Commanding  Officer  carries  the  responsibility  for  the  activities  of  the  Marine  Barracks 
companies,  one  of  which  is  the  MCI  Company.  (MCI  In-Brief,  1996) 

The  Deputy  Director  is  accountable  to  the  Director  of  MCI.  This  billet  is  staffed  by 
a  Marine  Corps  Lieutenant  Colonel.  This  position  is  responsible  for  the  performance  of 
MCI  Company  in  executing  the  seven  MCI  mission  tasks  identified  in  Chapter  II.  (MCI 
In-Brief,  1996) 

MCI  Company  is  composed  of  six  departments:  Headquarters  Department, 
Professional  Military  Education  Department,  Occupational  Skills  Department,  Logistics 
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Department,  Student  Services  Department  and  Management  Information  Systems 
Department.  The  authors  also  considered  Marine  Corps  unit’s  Training  Departments  to  be 
a  department  because  of  its  functions  in  the  administration  of  student  records.  (MCI  In- 
Brief,  1996) 

The  Headquarters  Department  is  composed  of  four  sections:  Administration 
Section,  Operations  and  Training  Section,  Edit  Division  and  Performance  Improvement 
Requirements  (PIR)Section.  Headquarters  Department  exercises  staff  cognizance  over  the 
MCI's  departments  for  the  production  and  support  of  distance  education  and  training 
materials.  (MCI  In-Brief,  1996) 

The  Professional  Military  Education  Department  (PMED)  consists  of  six  divisions: 
Command  and  Staff  College  Nonresident  Program  Division,  Amphibious  Warfare  School 
Nonresident  Program  Division,  Warfighting  Skills  Nonresident  Program  Division, 
Sergeants  Nonresident  Program,  Staff  Non-Commissioned  Officer  (SNCO)  Career 
Nonresident  Program  and  Staff  Non-Commissioned  Officer  (SNCO)  Advanced 
Nonresident  Program  Division.  PMED  provides  distance  education  that  is  a  prerequisite 
for,  or  parallels.  Mar  ne  Corps  resident  school  curricula.  (MCI  In-Brief,  1996) 

The  Occupational  Skills  Department  (OSD)  is  comprised  of  seven  divisions: 
Command  and  Control  Division,  Combat  Operations  Division,  Combat  Support  Division, 
Combat  Service  Support  (CSS)  Operations  Division,  Administration/Finance  Division,  Job 
Aids  Division,  and  Graphics/Layout  Division.  OSD  develops  and  maintains  nonresident 
courseware  and  military  occupational  specialty  (MOS)  specific  job  aids,  to  include  the 
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Marine  Battle  SkiUs  Training  and  the  Battle  Drill  Guide  for  use  by  the  active  and  reserve 
components  of  the  Marine  Corps.  (MCI  In-Brief,  1996) 

The  Logistics  Department  is  comprised  of  six  divisions:  Stock  Control  Division, 
Demands/Fiscal  Division,  Property  Control/Support  Division,  Warehousing  Division, 
Postal  Division,  and  Reproduction  Division.  Logistics  Department  procures,  stocks, 
packages,  and  distributes  courses  and  training  products,  produces  and  manages  the  fiscal 
plan,  provides  postal  services,  organizational  supply,  logistical  support,  printing  and 
reproduction  services  to  MCI  and  Marine  Barracks.  (MCI  In-Brief,  1996) 

The  Student  Services  Department  (SSD)  is  comprised  of  five  sections:  Immediate 
Assist  Section,  Enrollment  Section,  Grading  Section,  Unit  Activity  Report  (UAR)  Section, 
and  Registrar  Section.  SSD  is  responsible  for  the  enrollment,  grading,  and  management  of 
student  records  for  MCI’s  distance  education  and  training  programs.  (MCI  In-Brief,  1996) 
The  Management  Information  Systems  Department  (MISD)  is  comprised  of  two 
sections:  Information  System  Management  (ISM)  Section  and  Programming  Section. 
MISD  provides  information  systems  support  to  the  Marine  Barracks  and  to  MCI  in  the 
enrollment,  grading,  and  management  of  student  records.  (MCI  In-Brief,  1996) 

The  Marine  Corps  unit  Training  Department  is  normally  one  person,  the  unit 
Training  NCO.  The  Training  NCO  is  a  MCI  representative  within  the  Marine  Corps  unit, 
in  much  the  same  way  as  Lieutenant  Colonel  Harllee  set  up  when  correspondence  courses 
were  first  offered  77  years  ago. 
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2.  Business  Locations 


The  physical  location  of  each  organizational  unit  is  important  to  the  development 
of  technical  architecture.  It  provides  a  basis  for  determining  the  physical  attributes  the 
information  system  must  satisfy  for  the  business  activities  of  the  enterprise.  (Martin, 
1990B) 

A  tour  of  MCI  during  the  initial  brief  revealed  the  location  of  the  MCI  offices  and 
work  spaces  where  the  various  business  activities  take  place.  The  office  for  Director  of 
MCI  is  located  at  the  Marine  Barracks,  8*  and  I  streets.  This  is  approximately  six  blocks 
from  the  MCI  buildings.  The  office  for  the  Deputy  Director  is  located  on  the  second  floor 
in  building  220,  Lejeune  Hall,  at  the  Washington  Navy  Yard.  MCI  Headquarters 
Administrative  and  PIR  sections,  PMED,  SSD  and  MISD  are  also  located  on  the  second 
floor  of  Lejeune  HaU.  OSD,  Operations  and  Training  section,  and  the  Edit  Division  are 
located  on  the  first  floor  of  Lejeune  Hall.  The  Logistics  Department  is  located,  across  the 
street  from  the  rest  of  MCI,  in  building  169  of  the  Washington  Navy  Yard.  The  Marine 
Corps  unit’s  Training  Department  is  located  in  literally  hundreds  of  operating  locations 
around  the  world. 

3.  Business  Functions 

The  enteipiise  business  functions  were  decomposed  from  seven  high-level 
functional  areas.  Functional  areas  refer  to  the  major  business  activities  and  serve  as  the 
starting  point  for  further  decomposition  in  the  subsequent  Business  Area  Analysis.  The 
functional  decomposition  of  MCI’s  enterprise  activities  is  illustrated  in  Figure  13. 

•  Headquarters  Support  -  The  functions  that  provide  planning,  parade  support 
and  personnel  administration  for  MCI. 


•  Course  Development  -  The  functions  that  support  the  design,  writing,  revising, 
staffing,  and  production  of  MCI  courses,  programs,  and  job  aids. 

•  Course  Management  -  The  functions  that  support  the  advertising,  budgeting, 
training  and  analysis  of  MCI  courses,  programs,  and  job  aids. 

•  Student  Services  -  The  functions  that  support  data  entry  for  student  record 
management,  student  servicing,  grading,  and  course  completion  certification. 

•  Information  System  Management  -  The  functions  that  support  the  network 
management,  programming  and  database  administration  for  MCI. 

•  Warehouse  and  Distribution  -  The  functions  that  support  purchase,  receipt, 
storage,  inventory,  packaging,  distribution  and  disposal  of  MCI  courses, 
programs,  and  job  aids. 

•  Unit  Interaction  -  The  functions  performed  by  the  Marine  Corps  unit  training 
departments  in  support  of  the  administration  of  MCI  courses,  programs,  and 
job  aids. 


Figure  1?.  MCI  Enterprise  Level  Functional  Area  Decomposition. 
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A  business  function  is  a  collection  of  related  activities  which  completely  support 
one  aspect  of  furthering  the  enterprise’s  mission  (Martin,  1990B).  Figure  14  provides  an 
overview  of  many  functions  performed  by  the  various  organizational  units  in  the 
development,  distribution  and  management  of  the  distance  training  and  education  courses 
and  programs.  The  functions  represented  in  the  flowchart  were  used  to  generate  an  initial 
candidate  list  of  business  functions  performed  by  the  MCI  enterprise.  The  business 


function  candidate  list  was  revised  several  times  as  each  organizational  unit  was  analyzed. 
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Figure  14.  Product  Development,  Distribution,  and  Management  Howchart. 
Business  functions  were  then  defined.  Defining  the  business  functions  is  important 


to  understanding  the  business  process  as  a  whole.  However,  at  the  enterprise  level, 
business  function  definitions  are  independent  of  the  organizational  stmeture  (Martin, 
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1990B).  The  definitions  were  not  linked  directly  to  an  MCI  organizational  unit  or  its 
location  because  the  reporting  structure  may  change  but  the  functions  still  must  be 
performed.  A  total  of  33  candidate  business  functions  were  identified  and  defined  during 
the  enterprise  analysis; 

•  Advertising  -  To  publish  or  announce  the  availability  of  Programs,  Courses 
and  Job  Aids  in  the  MCI  Course  Catalog,  military  newspapers,  ALMARs, 
MARINE  magazine,  etc. 

•  Analysis  Of  Effectiveness  -  To  collect  data  from  returned  exams  and  student 
feedback  sheets,  and  analyze  data  in  order  to  revise  exam  questions  or 
Program  and  Course  text. 

•  Budgeting  -  To  manage  budget  categories  for  developing,  producing  and 
distributing  MCI  Programs,  Courses  and  Job  Aids. 

•  Course  Design  -  To  identify  and  establish  the  design  specifications,  schedule 
and  prerequisites  for  MOS  Courses  and  Job  Aids  to  meet  Marine  Corps 
training  and  education  requirements  for  target  audience. 

•  Course  Revising  -  To  revise  Job  Aids  and  MOS  Course  text,  examinations  and 
related  material  based  on  feedback  from  students.  Course  sponsors,  CG, 
MCCDC  a  id  internal  analysis  of  effectiveness. 

•  Course  Staffing  -  To  allow  newly  designed  MOS  Courses  and  Job  Aids  to  be 
reviewed  by  all  of  the  agencies  and  departments  responsible  for  its  production 
and  distribution. 

•  Course  Writing  -  To  research  and  write  the  MOS  Course  text,  components, 
examinations  and  Job  Aids. 

•  Customer  Servicing  -  To  respond  to  customer  inquiries  of  any  nature  (as  it 
relates  to  the  MCIAIS)  and  process  customer  requests  for  MCI  action 
(eiuollment,  material  request,  update  information,  etc.).  This  service  supports 
inquiries  received  by  telephone,  electronic  mail,  U.S.  Mail,  or  over  the  counter. 

•  Database  Administration  -  To  download  and  upload  TFS  and  unit  diary 
informatic  n  into  the  MCIAIS;  to  upload  and  service  the  automated  telephone 
Conversant  system  database.  To  commit  daily  transaction  files;  to  troubleshoot 
database  or  related  problems;  to  backup  database. 
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•  Delivering  -  To  deliver  Program  materials.  Course  materials.  Job  Aids, 
Diplomas,  Course  Completions  certification  and  course  components  to 
students. 

•  Disposing  -  To  purge  obsolete  Program  and  Course  materials.  Job  Aids  and 
course  components. 

•  Editing  -  To  review  new  and  revised  Programs,  Courses  and  Job  Aids  for 
Instructional  System  content  and  quality. 

•  Exam  Proctoring  -  Monitoring  examinations  to  Marines  in  the  fleet  to  ensure 
compliance  with  the  MCI  Procedures  Manual. 

•  Grading  -  To  record  the  scores  of  examinations,  in  the  MCI  student  database, 
graded  by  both  automated  &  manually  means. 

•  Inventory  -  To  manage  on-hand  quantities  and  locations  of  on-hand  material. 

•  Layout  &  Graphics  -  To  create  new  graphics,  improve  existing  graphics,  and 
maintain  library  of  appropriate  graphics  and  artwork  for  Program  text.  Course 
text,  and  Job  Aids. 

•  Manage  Networks  -  To  install,  manage  and  maintain  telephone  and  data 
network  equipment. 

•  Ordering  -  To  requisition  Program  and  Course  materials,  Job  Aids  and  course 
components  distributed  by  MCI. 

•  Packaging  -  To  assemble  and  shrink  wrap  Program  and  Course  materials.  Job 
Aids  and  course  components  for  distribution  and  storage. 

•  Parade  Support  -  To  coordinate  MCI  personnel  to  support  the  ceremonial 
activities  at  the  Marine  Barracks. 

•  Planning  -  To  schedule  and  coordinate  all  planning  associated  with  MCI 
Parades  and  Ceremonial  Details  involving  MCI  personnel. 

•  Program  Design  -  To  identify  and  establish  the  design  specifications,  schedule 
and  prerequisites  for  PME  comses  to  meet  Marine  Corps  training  and 
education  requirements  for  target  audience. 

•  Program  Revising  -  To  revise  PME  Program  text,  examination  and  related 
material  subject  to  feedback  from  students.  Program  sponsors,  CG,  MCCDC, 
and  internal  analysis  of  effectiveness. 
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•  Program  Staffing  -  To  allow  a  newly  designed  or  revised  PME  Program 
content  to  be  reviewed  by  aU  of  the  agencies  and  departments  responsible  for 
its  production  and  distribution. 

•  Program  Writing  -  To  research  and  write  the  PME  Program  text,  components 
and  examinations. 

•  Programming  -  To  write  program  source  code  that  corrects  or  enhances 
database  administration. 

•  Receiving  -  To  receipt  for  materials  that  will  be  stored  in  the  warehouse. 

•  Registrar  Servicing  -  To  research  and  produce  diplomas,  completion 
certificate.s  and  transcripts  for  students. 

•  Reproduction  Servicing  -  To  prepare  negatives,  camera-ready  originals,  and 
print  specifications  for  contract  orders  to  commercial  printers,  maintain 
negatives  and  camera-ready  copy  for  MCI  courses;  to  reproduce/print  original 
documents  for  MCI  or  Marine  Barracks  in  quantities  less  than  25,000. 

•  Storing  -  To  stock  received  materials. 

•  Student  Activity  Transactions  -  To  manage  student  records  and  monitor  the 
transaction  processing  system. 

•  Training  -  To  coordinate  training  of  MCI  course  writers  and  programmers. 

•  Unit  Reconciling  -  To  provide  MCI  with  feedback  from  units  so  MCIAIS  can 
be  validated  and  updated  if  required. 

4.  Data  Subjects 

Data  subjects  refer  to  a  higher  level  grouping  of  data  entities.  A  candidate  list  of 
data  subjects,  provided  in  Table  4,  was  developed  by  the  NPS  team  data  modeler.  The 
candidate  list  of  data  subjects,  their  definitions,  attributes  and  relationships  are  detailed  in 
the  Analysis,  Design,  and  Prototype  Implementation  of  a  Contemporary  Information 
System  for  the  Marine  Corps  Institute,  Preliminary  Report,  (Kamel  et  al.,  1997).  The  data 
subjects  were  decomposed  in  the  subsequent  Business  Area  Analysis. 
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Advertisement  Information 

Job  Aid  Information 

Component  Information 

Job  Aid  Copy  Material  Information 

Copy  Material  Information 

MCI  Personnel  Information 

Course  Information 

MCTFS  Personnel  Information 

Course  Copy  Material  Information 

Order  Information 

Course  Developers  Information 

Program  Information 

Customer  Information 

Program  Copy  Material  Information 

Events  Information 

Program  Developers  Information 

Exam  Information 

Purchase  Information 

Financial  Information 

SSD  Personnel  Information 

Inventory  Information 

Student  Information 

IS  Equipment  Inventory  Information 

Training  Information 

Issue  Complaint  Information 

Warehouse  Information 

Table  4.  Candidate  List  of  Data  Subjects. 

D.  DOCUMENT  THE  ENTERPRISE 

The  second  part  of  the  ISP  stage  documents  the  information  requirements, 


identified  during  the  first  part.  Graphic  representations  helped  to  summarize  the  collected 
data.  The  enterprise  analysis  of  MCI  was  documented  with  an  organization  chart  and 
several  planning  matrices  which  illustrate  the  relationships  of  MCFs  organizational  units, 
locations,  business  functions  and  data  subjects. 

1.  Document  Current  MCI  Organization 

The  reporting  structure  of  MCI  Company  was  documented  using  an  organizational 
chart  The  organization  chart.  Figure  15,  illustrates  the  hierarchical  structure  common 
among  traditional  military  organizations.  The  sections  are  logically  arranged  to  report  to 
the  respective  departments.  The  dashed  lines  represent  indirect  operational  support.  In  one 
case,  the  MCI  Company  provides  parade  and  logistical  services  to  the  Marine  Barracks 
operations.  In  the  other  case.  Marine  Corps  units  provide  enrollment  processing  and 
reconciliation  services  necessary  for  MCI  distance  training  operations. 
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Figure  15.  MCI  Company  Organization  Chart. 

2.  Document  Current  Locations,  Functions,  and  Data  Subjects 

The  relationships  between  the  organizational  units,  locations,  functions  and  data 

subjects  define  the  architectural  framework  of  the  enterprise.  A  common  technique  used  to 
document  and  analyze  such  relationships  is  to  develop  a  series  of  planning  matrices  that 
cross  reference  and  validate  the  various  elements  of  the  organization.  Eight  matrices  were 


used  to  define  the  information  and  business  system  architecture  for  the  MCI  enterprise 
analysis:  Organizational  Unit  versus  Location,  Function  versus  Orgaitizational  Unit, 
Function  versus  Location,  Data  Subject  versus  Organizational  Unit,  Data  Subject  versus 
Location,  Data  Subject  versus  Function  (CRUD  Matrix),  Function  versus  Data  Subject 
(CR  Matrix)  and  Function  versus  Data  Subject  (Clustered  CR  Matrix). 

The  Organizational  Unit  versus  Location  matrix,  provided  as  Figure  16, 
summarizes  the  MCI  organizational  units  and  the  locations  where  their  business  activity 
takes  place.  The  matrix  validated  the  organizational  units  with  their  locations.  This 
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Figure  16.  Organizational  Unit  versus  Location  Matrix. 


validation  ensured  all  organizational  units  were  accounted  for  in  the  analysis.  Their 
locations  would  be  considered  in  the  technical  architecture  development.  The  ’’marks  in 
the  same  columns  depict  organizational  units  which  operate  from  the  same  location.  The 
marks  in  the  same  rows  indicate  organizational  units  which  operate  in  different  locations. 

The  Function- versus  Organizational  Unit  Matrix,  provided  as  Figure  17, 
summarizes  the  functions  performed  by  each  MCI  organizational  unit  The  Function  • 
versus  Location,  provided  as  Figure  18,  summarizes  the  locations  in  which  the  functions 
are  performed.  These  two  matrices  validated  the  functional  decomposition  by  ensuring 
that  every  function  was  mapped  to  an  organizational  unit  and  that  every  organizational 
unit  was  involved  in  an  identified  function.  The  matrices  also  show  the  extent  to  which 
departments  share  data  and  perform  redundant  functions. 
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Figure  17.  Function  versus  Organizational  Unit  Matrix. 

Two  other  matrices  were  produced  by  the  NFS  data  modeler  to  illustrate  the 
relationship  between  the  data  subjects  with  the  organizational  units  and  the  locations. 


Ill 


Figure  18.  Function  versus  Location  Matrix. 

Together,  these  five  matrices  served  to  cross  reference  and  validate  the  candidate  data 
subjects  and  business  functions  and  improved  the  project  team’s  understanding  of  MCI’s 
current  strategy  for  conducting  business. 

The  relationship  between  business  functions  and  the  data  subjects  revealed  the 
Information  Architecture.  Three  matrices  were  used  to  group  business  functions  and  data 
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subjects  into  natural  business  systems  and  natural  data  stores.  These  groupings  identify  the 
division  of  business  areas  in  preparation  for  further  detailed  analysis. 

Each  function  was  evaluated  to  determine  if  it  would  create,  read,  update,  delete, 
or  archive  the  corresponding  data  subject.  A  “C”,  “R”,  “U”,  “D”  and/or  “A”  was  placed  in 
the  row-column  representing  that  data  subject  and  function  analyzed.  Collating  each 
combination  produced  the  Data  Subject  versus  Function  CRUD  Matrix  given  as  Figure 
19. 

A  CR  Matrix,  provided  as  Figure  20,  was  used  as  an  intermediate  step  to  generate 
the  groupings  necessary  to  identify  the  business  areas.  A  “C”  was  substituted  for  every 
“C”,  “U”,  “D”  or  “A”.  The  columns  and  rows  of  the  CR  Matrix  were  arranged  to  create 
clusters  of  related  functions  that  create,  update,  delete  and  archive  associated  data 
subjects.  The  resulting  Clustered  CR  Matrix  revealed  natural  groupings  that  verify  the 
natural  division  of  sub-systems  in  preparation  for  the  Business  System  Design  stage. 

3.  MCI’s  Current  Business  Model 

The  Clustered  CR  Matrix,  provided  as  Figure  21,  revealed  eight  business  sub¬ 
systems  that  directly  influence  the  MCI  mformation  requirements:  Personnel 
Administration,  Ceremonial,  Program  and  Course  Development,  Program  and  Course 
Management,  Student  Service  Support,  Information  System  Management,  Warehouse  and 
Distribution,  and  Unit  Interaction. 

The  Clustered  CR  Matrix  revealed  two  details  worthy  of  discussion.  First,  the 
Personnel  Administration  and  Ceremonial  sub-systems  influence  business  activity  of  MCI 
but  actually  have  no  direct  interface  with  MCIAIS.  Second,  the  Unit  Interaction  sub- 
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Figure  19.  Data  Subject  versus  Function  (CRUD)  Matnx. 
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Figure  19.  Data  Subject  versus  Function  (CRUD)  Matrix  continued. 
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Figure  21.  Clustered  CR  Matrix. 
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system  uses  data  produced  by  MCIAIS  and  generates  data  input  through  MISD,  but  does 
not  actually  create  or  read  a  data  subject  directly.  These  three  sub-systems  were  left  in  the 
matrix  to  give  a  complete  representation  of  the  business  system  architecture  to  consider 
during  the  reengineering  phase. 

The  MCI  Preliminary  Business  Model,  Figure  22,  represents  the  division  of  the 
enterprise  into  lowei  evel  business  areas  and  functions.  Subsequent  analysis  of  each 
business  area  can  be  performed  independently  based  on  priorities  determined  during  this 
initial  evaluation  to  s  .risfy  the  organizational  requirements.  MCI  management  determined 
the  business  activities  of  Student  Service  Support  should  receive  the  highest  priority  based 
on  the  information  requirements  and  its  role  in  the  MCIAIS-H  implementation  plan. 

The  boundaries  of  the  business  area  analysis  for  Student  Service  Support  adds 
definition  to  the  MCI  Modernization  Project  scope.  The  analysis  did  not  focus  on  how  the 


Figure  22.  MCI  Preliminary  Business  Model. 
118 


database  was  populated,  but  on  the  data  with  which  it  would  be  populated,  the  SSD 
processes  that  use  the  data,  and  the  interaction  between  the  two.  The  key  business  areas, 
functions,  and  data  subjects,  identified  during  the  MCI  enterprise  analysis,  are  illustrated 
with  Figure  23.  The  business  areas  are  represented  by  large  rounded  boxes.  The  functions 
are  represented  are  C(  :r,tained  within  the  respective  business  area.  External  entities  are 
represented  with  rectangles.  The  arrows  represent  interaction.  The  dashed  line  represents 
the  boundary,  and  focus  of  the  BAA.  Migration  of  the  legacy  system’s  functionality 
required  identification  of  the  data  entities  encountered  with  each  interaction.  The  As-Is 
process  model  was  developed  to  identify  those  details. 
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VII.  MCI  BUSINESS  AREA  ANALYSIS 


This  chapter  further  describes  the  process  modeling  effort  in  support  of  the  MCI 
modernization  projec  .  The  chapter  begins  with  a  detailed  description  of  the  Business  Area 
Analysis  and  the  subsexjuent  development  of  the  As  Is  Model  for  the  Student  Services 
Support  business  aret.  The  detailed  description  of  the  tailored  application  of  Business 
Process  Reengineering  follows.  The  chapter  concludes  with  the  presentation  of  To  Be 
Process  and  Information  System  Models  for  the  Student  Services  Department. 

A.  BUSINESS  AREA  ANALYSIS  OVERVIEW 

The  Business  Area  Analysis  (BAA)  is  the  second  stage  of  Information 
Engineering.  The  BAA  is  a  refinement  to  a  specific  subset  of  the  enterprise  analysis.  There 
are  six  objectives  of  a  BAA  project  (lEF  Guide,  1990): 

1 .  To  fuUy  identify  and  define  the  type  of  data  required 

2.  To  identify  and  define  the  business  activities  that  make  up  each  business 
function 

3.  To  define  the  data  required  for  each  business  activity 

4.  To  identify  the  necessary  sequence  of  business  activities 

5.  To  define  how  business  activities  affect  the  data 

6.  To  produce  a  plan  for  Business  System  Design  (BSD)  within  a  prioritized 
sequence  of  business  systems.  Normally,  several  business  systems  will  be 
defined  to  support  a  single  business  area. 

The  ultimate  goal  is  to  refine  the  business  areas  identified  during  the  enterprise 
analysis.  The  ISP  stage  targeted  the  Student  Service  Support  as  the  first  business  area  for 
detailed  analysis.  Boundaries  were  established  to  identify  the  resources  required  to  support 
development  of  a  nev  information  system  that  will,  at  least,  maintain  the  same 
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functionality  provided  by  the  current  MCIAIS  in  a  new  relational  database.  The  detailed 
analysis  focused  on  definition  and  refinement  of  the  business  activities  performed  by  SSD, 
the  objects  that  generate  the  activity,  and  the  interaction  between  them. 

B.  MCI  BUSINESS  AREA  ANALYSIS 

The  BAA  for  Student  Service  Support  is  built  upon  the  information  gathered 

during  the  ISP  stage.  Having  already  identified  the  functional  areas  and  the  business  area 
to  analyze,  the  NPS  team  initiated  development  of  the  As-Is  Process  Model.  A  detailed 
functional  decomposition  of  the  Student  Service  Support  business  area  was  done.  The  As- 
Is  process  model  was  presented  as  node  tree  and  process  decomposition  diagrams  and 
circulated  for  review.  Business  Process  Reengineering  techniques  were  applied.  A  To-Be 
process  model  was  developed  using  IDEFO  modeling  technique.  The  proposed  To-Be 
Process  Model  was  circulated  again  for  review.  The  refined  model  was  validated  using 
matrices  and  clustering  as  performed  during  the  ISP  stage.  Once  validated,  an  information 
system  model  was  de  eloped  using  data  flow  diagrams.  The  products  of  this  analysis 
provided  the  necessary  information  to  develop  a  system  architecture  plan,  a  To-Be  Data 
model,  a  To-Be  Proc  ss  model,  an  information  system  model,  and  a  prototype  that 
validated  the  methodology. 

1.  SSD  BAA  Implementation 

The  As-Is  process  model  represents  the  business  activity  of  the  Student  Services 
Department  in  August  1996.  Model  development  began  with  functional  decomposition. 
The  student  service  support  business  area  was  decomposed  eight  levels  into  499  activities. 
A  process  decomposition  diagram  and  node  tree  diagrams  were  developed  to  document 
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the  analysis.  This  tec)inique  provided  sufficient  detail  to  obtain  a  thorough  understanding 
of  SSD  business. 

The  process  decomposition  and  node  tree  diagrams  were  developed  with  the 
BPWin®  CASE  tool.  BPWin®  was  useful  for  the  development  of  the  metadata 
encyclopedia.  It  proved  to  be  very  simple  to  use  and,  after  receiving  a  software  patch, 
integrated  well  with  its  sibling  data  modeling  CASE  tool,  ERWin®. 

A  complete  IDEFO  model  was  not  produced  for  the  As-Is  processes.  The  authors 
felt  that  too  much  time  would  be  spent  developing  naming  conventions  for  activities, 
relationships  and  entities  of  the  non-relational  database,  which  would  detract  from  the 
reengineering  effort.  However,  the  activities  that  were  likely  to  apply  in  the  To-Be  process 
model  were  defined  aid  then  refined  when  applied. 

During  the  reengineering  phase  it  became  apparent  that  an  As-Is  process  should 
also  include  selected  processes  fi:om  other  functional  areas.  Sufficient  information  had 
been  obtained  during  the  ISP  stage  to  create  high-level  As-Is  process  models  for  other 
business  areas:  Course  and  Program  Management,  Course  and  Program  Development, 
Warehouse  and  Distribution,  and  Information  System  Management. 

These  decomposition  diagrams  were  useful  in  the  data  model  development.  The 
enterprise  level  CRUD  matrix  revealed  a  significant  amount  of  data  retrieved  by  SSD  but 
owned  by  other  business  areas.  Course  or  program  information,  stock  status,  MCTFS 
information  are  just  a  few  examples.  The  data  model  needed  to  reflect  those  data  subjects 
for  MCIAIS-n  to  retain  the  same  functionality. 
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2.  As-Is  Model  Details 


All  of  the  activities  depicted  in  the  SSD  process  model  are  prefixed  with  “SSD”  to 
distinguish  it  from  models  developed  for  other  areas.  Since  the  SSD  As-Is  process  model 
is  too  large  to  print  as  a  single  document,  it  was  broken  into  modules  for  readability.  Only 
selected  material  will  be  presented  to  illustrate  specific  points.  The  model  is  provided  in  its 
entirety  as  Appendix  B. 

The  number  of  activities  clearly  demonstrates  the  level  of  detail  pursued  in  the 
BAA  of  Student  Services.  This  detail  provided  the  NFS  team  with  a  thorough 
understanding  of  SSD  activity.  Additional  model  details  must  be  gleaned  from  careful 
study  of  the  process  decomposition  diagram  or  the  node  tree  diagrams  included  as  exhibits 
to  Appendix  B  of  the  Analysis,  Design,  and  Prototype  Implementation  of  a  Contemporary 
Information  System  for  the  Marine  Corps  Institute,  Final  Report,  (Kamel  et  al.,1997). 

a.  Functional  Decomposition 

The  business  area  of  Provide  Student  Support  was  decomposed  eight  levels 
down  to  the  primitive  processes  -  a  total  of  499  activities.  The  first  level  identified  six 
functions:  OBTAIN  CUSTOMER  INPUT,  MAKE  CHANGES  TO  STUDENT’S 
COURSE  ACTIVITY  RECORD,  GRADE  STUDENTS  EXAMINATIONS,  PROCESS 
UNIT  ACTIVITY  REPORTS,  PROCESS  REQUESTS  FOR  MATERIAL,  and 
PROCESS  REQUEST  FOR  REGISTRAR  ACTION.  Figure  B-1,  Appendix  B  is  a  node 
tree  diagram  of  the  top  three  levels. 

The  OBTAIN  CUSTOMER  INPUT-  SSDl  function  was  decomposed  into 
four  processes:  PROCESS  INCOMING  PHONE  CALLS,  SORT  INCOMING  U.S.  MAIL, 
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SORT  INCOMING  ELECTRONIC  MAIL,  and  PROCESS  WALK-IN  CUSTOMERS.  This 
function  represents  the  front  end  of  customer  service  by  receiving  and  replying  to 
customer  requests.  One  other  method  of  customer  processing  is  through  the  Marine  Corps 
Unit  Diary  System.  This  method  however  is  a  process  performed  within  the  Information 
System  Management  business  area  and  requires  no  student  services  interface. 

The  MAKE  CHANGES  TO  STUDENT’S  COURSE  ACTIVITY 
RECORD  -  SSD2  function  was  decomposed  into  four  processes:  PROCESS  REQUEST 
FOR  ENROLLMENT,  PROCESS  CHANGE  TO  STUDENT  INFORMATION,  PROCESS 
REQUEST  FOR  ADMINISTRATIVE  ACTION,  and  PROCESS  STANDARD  REQUEST 
FOR  MATERIAL.  This  function  represents  most  of  the  user  interface  with  MCIAIS.  This 
activity  is  replicated  as  sub-processes  below  OBTAIN  CUSTOMER  INPUT.  In 
developing  the  As-Is  model,  the  authors  intended  to  use  the  replicated  processes  to  model 
the  different  modes  of  access  to  MCI  as  a  target  for  reengineering. 

The  GRADE  STUDENTS  EXAMS  -  SSD3  function  was  decomposed  into 
four  processes:  PROCESS  PRE-SLUGGED  DP -37s,  PROCESS  GENERIC  DP-37s, 
PROCESS  OPSCAN  ERROR  USTING  REPORT,  and  PROCESS  HAND  GRADED 
EXAMS.  This  function  represents  processing  student  lessons  and  examinations  and 
products  resulting  form  the  activity. 

The  PROCESS  UNIT  ACTIVITY  REPORTS  -  SSD4  function  was 
decomposed  into  two  processes:  WORK  RETURNED  UARs  and  PROCESS  OUTGOING 
UARs  BY  US  MAIL.  This  function  represents  the  reconciliation  processes  between  MCI 
and  the  Marine  Corps  unit  Training  NCO. 
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The  PROCESS  REQUEST  FOR  MATERIAL  -  SSD5  function  was 
decomposed  into  four  processes:  SEGREGATE  REQUEST  FOR  REGISTRAR  ACTION, 
SEGREGATE  STANDARD  REQUESTS  FOR  MATERIAL,  PROCESS  “REQUEST  FOR 
MATERIAL’^  FORMS,  and  SEGREGATE  “OFF-UNE  REQUEST’  FORMS.  This 
function  represents  the  processes  to  satisfy  customer  requests  for  new  or  replacement 
materials.  Many  of  these  activities  are  replicated  as  lower  level  sub-processes  in  SSDl. 

The  PROCESS  REQUESTS  FOR  REGISTRAR  ACTION  -  SSD6 
function  was  decomposed  into  two  processes:  ISSUE  (REISSUE)  DIPLOMA  and 
PROCESS  TRANSCRIPT  REQUEST.  This  function  represents  the  activities  of  issuing 
diplomas  and  transcripts. 

b.  Detailed  Analysis 

The  detailed  analysis  was  done  by  reviewing  each  provided  SSD  task 
breakdown  sheet  and  modeling  the  activities  described.  Additional  details  were  obtained 
from  the  MISD’s  Standard  Operating  Procedures  manual,  the  Marine  Corps  Institute 
Procedures  Manual,  telephone  interviews,  and  replies  to  our  specific  requests. 

Model  development  revealed  a  significant  number  of  manual  activities.  This 
drew  a  lot  of  attention  because  the  manual  processes  seemed  to  cause  a  bottleneck  to 
production  flow.  Modeling  manual  activities  effectively  during  the  As-Is  effort  simplified 
the  subsequent  reengineering  effort. 

OBTAIN  CUSTOMER  INPUT,  activity  number  SSDl,  models  the 
process  of  receiving  customer  input.  Figine  B-2,  Appendix  B  is  a  node  tree  diagram  which 
illustrates  four  levels  of  that  function’s  decomposition.  The  figure  depicts  the  flexibility 


126 


MCI  applies  to  servicing  customers  by  receiving  their  input  in  various  forms:  telephone, 
walk-in,  electronic  mail,  and  U.S.  Mail.  The  model  also  demonstrates  a  relatively  standard 
method  of  handling  the  input.  Telephone  and  walk-in  customers  receive  immediate 
attention  while  all  other  input  is  sorted  and  segregated  for  assembly  line  processing. 

U.S.  mail  processed  by  the  Student  Services  Department  is  opened  and  the 
contents  manually  segregated  for  subsequent  distribution.  MCI  administrative  procedures 
specify  that  enrollment  requests  are  submitted  with  an  MCI  Enrollment  Application  Card 
(R-1  Card).  Other  requests  are  submitted  with  a  Student  Requesfdnquiry  Form  (R-11 
Card).  Lessons  and  examinations  are  submitted  on  two  different  sized  forms  of  an  optical 
character  recognition  (OCR)  capable  form  (DP-37).  One  form  was  pre-formatted  with 
student  and  course  information  and  distributed  with  the  course  materials  when  enrolled. 
The  other  is  a  generic  form  which  the  student  completes  when  the  examination  is  returned 
for  evaluation.  Course  materials  are  distributed  with  a  feedback  form  which  is  submitted 
when  a  lesson  or  exam  is  completed.  Many  of  the  Non-Resident  Program  examinations  are 
essay  type  and  not  OCR  capable.  All  requests  for  transcripts  must  also  be  written. 
Consequently,  there  is  a  single  point  of  entry  to  process  customer  input  by  U.S.  Mail. 

Electronic  mail  addressed  to  MCI  is  received  in  one  electronic, 
organization  mailbox  (0MB),  unless  addressed  to  an  individual.  Electronic  mail 
processing  has  not  been  standardized  except  for  electronic  Unit  Activity  Reports. 
Regardless  of  the  subject  matter,  all  electronic  mail  received  in  the  0MB  is  printed, 
segregated  and  distributed  for  subsequent  processing.  The  content  of  electronic  messages 
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cover  the  same  variety  of  input  as  U.S.  mail  minus  lesson  and  course  examinations, 
without  the  convenience  of  a  standard  format. 

A  student  or  Marine  Corps  unit  representative,  i.e..  Training  NCO,  First 
Sergeant,  section  non-commissioned  officer  in  charge,  can  obtain  course  status  through  an 
MCI  automated  voice  recognition  system  (AVRS)  called  Conversant.  The  caller  contacts 
MCI’s  toll  free  number,  inputs  the  student’s  social  security  number  and  course  number, 
and  Conversant  returns  the  student’  course  status.  Conversant  accesses  a  copy  of  the  MCI 
student  database  resident  on  a  remote  server. 

MAKE  CHANGES  TO  STUDENT’S  COURSE  ACTIVITY  RECORD, 
activity  number  SSD'!,  models  the  processing  transactions  that  effect  a  student’s  record 
within  MCIAIS.  Figure  B-3,  Appendix  B  is  a  node  tree  diagram  which  illustrates  four 
levels  of  that  function’s  decomposition.  Once  an  eru-ollment,  inquiry,  or  other  request  is 
received,  segregated  and  distributed,  processing  is  the  same  as  would  be  administered  for 
a  telephone  or  walk-in  customer.  The  same  screens  are  used  to  access  data  from  MCIAIS 
in  the  same  sequence  regardless  of  customer  entry  mode.  Transaction  codes  are  entered  by 
the  user  to  reflect  input  that  changed  student  activity  records.  A  list  of  transaction  codes 
are  maintained  near  each  user  terminal.  One  interface  characteristic  identified  user-entered 
data  is  not  carried  forward  when  transitioning  between  screens.  This  required  multiple 
entries  of  the  same  information  and  increased  the  likelihood  of  user  error. 

GRADE  STUDENTS  EXAMS,  activity  number  SSD3,  models  the 
processing  of  lessons  and  examinations  received  from  students  and  the  output  generated. 
Figure  B-4,  Appendix  B  is  a  node  tree  diagram  which  illustrates  four  levels  of  that 
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function’s  decomposition.  Two  t3^es  of  DP- 37s  are  processed:  pre-slugged  DP- 37s 
which  are  formatted  prior  to  distribution  course  material  issue,  and  generic  DP-37s  which 
are  not  The  DP-37s  contain  the  same  information  but  are  different  sizes.  They  must  be 
segregated  prior  to  processing.  The  DP-37s  are  scanned  by  an  OCR  reader,  Scantron,  and 
the  data  is  collected  iit  a  file  on  a  disk.  The  DP-37s  successfully  read  are  placed  in  a 
pending  file.  Those  not  read  must  be  hand  graded.  DP-37s  failed  scanning  because  of  form 
damage  or  key  fields  weren’t  completed.  The  disk  is  delivered  to  MISD  for  batch 
processing  during  the  nightiy  cycle. 

The  OPSCAN  Error  Report,  a  list  of  all  lessons  and  exams  not  processed 
by  MCIAIS,  is  produced  after  the  cycle  is  run.  The  DP-37s  on  that  list  must  be  pulled 
from  the  pending  file  and  manually  processed  according  to  the  error  code.  The  remaining 
scaimed  DP- 37s  are  moved  to  a  completed  file.  The  generic  DP-37  increased  the 
likelihood  of  incomplete  forms,  forms  completed  incorrectly,  and  forms  received  from 
individuals  who  hadn’t  been  enrolled.  The  generic  form  was  created  to  simplify  course 
material  packaging  aud  reduce  distribution  delays. 

Hand  graded  examination  and  PME  examination  scores  are  entered  into 
MCIAIS  manually.  Corrected  DP-37s  from  the  OPSCAN  Error  Report  are  either 
processed  through  the  Scantron  again  or  entered  into  MCIAIS  manually. 

PROCESS  UNIT  ACTIVITY  REPORTS,  activity  number  SSD4,  models 
the  process  of  reconciling  MCIAIS  student  record  activity  with  the  records  maintained  by 
the  Marine  Corps  unit.  Figure  B-5,  Appendix  B  is  a  node  tree  diagram  which  illustrates 
four  levels  of  that  function’s  decomposition.  Unit  Activity  Reports  (UARs)  are  generated 
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during  a  mid-month  and  monthly  cycle  batch  process  by  MISD.  UARs  are  produced  in 
electronic  form  only  during  the  mid-month  cycle  and  both  electronic  and  paper  form  at  the 
end  of  the  month.  The  unit  must  request,  reconcile  and  return  electronic  UARs  following 
procedures  set  forth  in  the  Marine  Corps  Institute  Procedures  Manual.  Procedures  for  unit 
reconciling  UARs  are  the  same  regardless  of  the  method  of  distribution.  The  unit  reports 
the  differences  with  annotations  to  the  UAR  and  returns  it  to  MCI.  MCI  processes  the 
changes  following  the  same  procedures.  Each  annotation  associated  with  a  student  record 
requires  that  record  to  be  viewed  on  a  terminal  screen  and  checked  to  see  if  that  record 
reflects  the  remark.  If  not,  the  change  is  entered  following  the  same  procedures  as 
described  during  activity  SSD2  -  MAKE  CHANGES  TO  STUDENT’S  COURSE 
ACnVITY  RECORD.  There  is  no  action  required  by  Student  Services  to  process 
outgoing  electronic  UARs.  The  UARs  that  are  produced  in  paper  form  must  be  packaged, 
addressed  and  mailed  to  units  not  on  electronic  distribution. 

PROCESS  REQUEST  FOR  MATERIAL,  activity  number  SSD5,  models 
the  process  of  responding  to  customer  and  student  requests  for  material.  Figure  B-6, 
Appendix  B  is  a  node  tree  diagram  which  illustrates  four  levels  of  that  function’s 
decomposition.  Material  requests  fall  into  four  general  categories:  standard  material 
request,  request  for  material,  off-line  request  for  material,  and  transcripts.  Each  category 
entails  a  greater  degree  of  manual  activity.  A  standard  material  request  has  a  transaction 
code  that  can  be  entered  at  the  terminal  and  MCIAIS  will  generate  a  mailing  label  for 
logistics  to  complete  the  distribution  process.  Material  in  this  category  includes:  a 
duplicate  issue  of  job  aids,  course  or  program  material,  issuing  course  or  program  material 


without  an  enxoUmen*,,  and  a  duplicate  issue  of  a  completion  certificate  or  diploma.  A 
request  for  material  is  for  material  required  to  support  the  Marine  Corps  unit  Training 
NCO  performing  MCI  liaison  functions.  Material  in  this  category  includes:  pre-addressed 
postage  paid  envelopes,  blank  DP-37s,  course  catalog.  Marine  Corps  Institute  Procedures 
Manuals,  R-1  Cards  and  R-1 1  Cards.  Activities  for  this  type  of  request  include  filling  out  a 
form,  packaging  the  material  from  stock  maintained  in  the  Student  Services,  addressing 
the  package  and  forwarding  the  package  to  Logistics  for  mailing.  Off-line  request  material 
is  for  an  individual  component  of  a  course,  program  or  job  aid  or  course  material  for  a 
foreign  military  officer.  This  requires  completion  of  a  different  form,  approval  by 
operations  officer,  preparation  of  an  address  label,  and  delivery  to  Logistics  for  mailing.  A 
transcript  request  must  be  in  writing.  It  is  delivered  to  the  registrar  for  processing  in 
accordance  with  activity  SSD6.2. 

PROCESS  REQUEST  FOR  REGISTRAR  ACTION,  activity  number 
SSD6,  models  the  production  of  transcripts  and  diplomas.  Figure  B-7,  Appendix  B  is  a 
node  tree  diagram  which  illustrates  fovu  levels  of  that  function’s  decomposition.  One  of 
the  MISD  grading  program  batch  processes  produced  a  diploma  print  file.  The  file  is 
transferred  to  a  disk  and  delivered  to  the  Registrar.  The  Registrar  produced  the  diplomas, 
duplicate  diplomas  and  envelopes  from  the  file  by  running  a  program  on  a  local  PC 
connected  to  a  LaserJet  printer.  Transcripts  must  be  individually  researched  using  active 
and  archived  MCIAiS  student  records  and  microfiche  records.  The  collected  data  is  put 
onto  a  form,  typed  on  a  computer  terminal,  printed  and  mailed. 
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Task  vvorksheets  provided  to  the  NFS  team  indicated  that  a  morning  report 
aggregated  the  number  of  telephone  calls  processed  daily,  the  number  of  examinations 
processed  -  successfully  and  unsuccessfully,  the  number  of  transcripts  requested  and 
distributed,  and  the  number  of  diplomas  distributed.  The  morning  report  was  manually 
collated.  However,  that  process  had  been  terminated  and  no  records  available  from  which 
to  extrapolate  historical  impact. 

c.  As-Is  Process  Model 

The  As-Is  process  model  documents  the  business  area  analysis  of  the 
cuirent  system.  Graphic  representations  helped  to  summarize  the  results.  The  business 
area  analysis  of  SSD  was  documented  with  a  decomposition  diagram  and  several  node  tree 
diagrams.  These  diagi'ams  illustrate  the  functional  decomposition  of  activities  performed 
to  administer  student  activity  records  in  MCIAIS.  The  process  model  is  provided  as 
Appendix  B. 

Manual  activities  within  a  process  model  add  definition  to  the  business 
system  architecture.  The  manual  processes  however,  can  lead  to  discontinuity  in  the 
information  and  technical  architecture.  A  large  number  of  manual  activities  prevents 
accurate  measurement  of  throughput  and  associated  cost.  This  is  one  reason  for  targeting 
their  elimination  during  reengineering. 

C.  REENGINEERING  THE  AS-IS  PROCESS  MODEL 

Reengineering  approaches  and  methodologies  were  discussed  in  Chapter  IV.  This 

section  addresses  the  business  environment  leading  to  the  selection  of  Harrington’s 
Business  Process  Inn  ovation  (BPI)as  the  reengineering  methodology  best  suited  for  MCI. 
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Following  the  assessment,  the  BPI  methodology  is  discussed  as  it  applies  to  the  current 
processes  at  MCI.  The  section  concludes  with  a  summary  that  leads  to  the  development  of 
the  To-Be  process  model. 

1.  Assessing  the  Reengineering  Environment 

The  information  gathered  during  the  enterprise  analysis  and  development  of  the 
As-Is  model  was  critical  to  understanding  MCI’s  business  environment  and  the  urgency 
with  which  reengineering  may  be  applied. 

a.  Reengineering  Category 

Initially,  the  authors  believed  MCI  fell  into  the  crisis  reengineering 
category.  Prior  to  August  1996,  the  Commandant  of  the  Marine  Corps  urged  MCI  to 
improve  its  level  of  customer  service.  Executive  level  interest  and  support  were  keen  and 
funding  was  readily  available.  Some  organizational  restructuring  was  already  underway 
and  demonstrating  marked  improvements.  In  spite  of  the  quick  fixes,  however,  the  need 
for  formal  reengineering  of  the  information  system  still  existed. 

Culturally,  MCI  is  a  traditional  organizational  hierarchy.  As  a  result,  MCI 
exhibited  great  resistance  to  notions  of  radical  transformation.  For  example,  MCI  was  not 
interested  in  suggestions  of  outsourcing  the  shipping  process  to  a  commercial  package 
delivery  company  or  moving  to  Internet  accessible,  on-line  enrollment  procedures  for 
customers.  It  was  evident  from  the  first  interviews  that  radical  changes  would  not  receive 
the  support  or  continuity  of  personnel  necessary  to  carry  radical  modernization  to  fruition. 
The  incremental  approach  of  the  life-cycle  reengineering  category  was  seen  as  the  best  fit 
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based  upon  the  expected  turnover  of  key  management  personnel  and  procurement 
schedule  of  the  replacement  system  architecture. 
b.  Reengineering  Ideals 

An  assessment  of  the  reengineering  ideals  provide  perspective  on  MCI 
business  environment  and  the  degree  of  commitment  to  modernization. 

Process  Orientation-  MCI  retains  much  of  the  outdated  management 
perspective  of  the  industrial  age.  It  is  primarily  task  organized  in  an  assembly  line  manner. 
A  major  reason  for  this  is  the  prevalence  of  combat  arms  personnel  staffing  key 
management  billets.  Transition  to  the  information  age  is  evident  and  a  new  information 
system  a  key  element  Another  key  element  is  a  paradigm  shift  from  task  orientation  to 
process  orientation  and  process  improvement 

Three  distinctive  processes  are  apparent  at  MCI.  The  first  is  information 
gathering  and  distribution:  maintaining  a  course  catalog  of  over  300  items,  maintaining 
the  addresses  and  course  history  of  over  one  million  students,  and  maintaining 
examination  question  banks  and  answers  for  over  160  courses.  The  second  process  is 
warehousing  and  shipping  of  catalog  items.  The  third  process  is  course  development  and 
writing  of  text  books  and  associated  material.  Many  reengineering  opportunities  exist  with 
this  wide  range  of  processes.  Other  initiatives,  outside  the  scope  of  this  project,  should 
address  the  MCI  logistics  and  course  development  processes,  leaving  the  information 
gathering  and  distribution  the  only  function  available  for  reengineering  as  part  of  this 
project.  This  function  is  performed  by  the  Student  Services  and  Information  Systems 
Management  Divisions  at  MCI. 
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Ambition  -  The  degree  of  ambition  is  reflected  in  the  number  of  protected 
processes.  It  is  also  reflected  by  the  amount  of  resistance  encountered  when  proposing  to 
reengineer  a  candidate  process.  This  became  obvious  during  the  circulation  of  the  SSD 
As-Is  process  model. 

Rule-breaking  -  The  effort  to  reduce  business  rules  often  requires  an 
understanding  of  existing  rules  in  place.  MCI  made  a  genuine  effort  to  document  their 
current  business  rules  in  force.  It  was  discovered  during  the  process  that  many  of  the  rules 
were  made  so  that  the  programmer  could  code  them.  While  business  rules  standardize 
operating  procedures,  complicated  conditions  proved  difficult  for  Marine  programmers  to 
understand  and  implement.  As  a  result,  considerable  effort  was  put  into  eliminating 
business  rules  attached  to  student  enrollments. 

Creative  use  of  information  technology  -  Information  technology  (IT) 
plays  a  key  role  in  BPR.  MCI  demonstrated  considerable  interest  in  this  ideal.  But  due  to 
limited  exposure,  not  all  personnel  are  aware  of  IT  opportunities  or  their  potential 
benefits.  Additionally,  the  acquisition  of  IT  resources,  for  the  military  in  general,  is  often  a 
lengthy  process  and  limits  the  more  immediate  results  that  can  be  achieved. 

The  delays  associated  with  procurement  of  IT  resources  may  provide  the 
time  for  the  reluctant,  or  undecided,  stakeholders  to  “buy-into”  the  reengineering  effort. 
This  buy-in  may  facilitate  the  integration  of  all  the  process  owners  as  effective  participants 
in  the  modernization  effort.  In  the  meantime,  a  continuous  process  improvement  approach 
is  necessary  to  complement  the  cultural  environment.  For  these  reasons,  the  selection  of 
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Harrington’s  BPI  methodology  was  determined  to  be  the  best  fit  for  applying  business 
process  reengineering  techniques  to  MCI. 

2.  Reengineering  Implementation 

Harrington’s  BPI  methodology  addresses  five  phases:  organizing  for 
improvement,  understanding  the  process,  streamlining,  measurement  and  control,  and 
continuous  improvement  The  authors  application  of  these  five  phases  discovered  that 
much  of  the  work  was  already  performed.  Further  investigation  found  evidence  that  an 
external  consultant  had  analyzed  MQ  and  many  improvements  were  already  implemented. 

Phase  I,  organizing  for  improvement.  This  phase  provides  structure  and  continuity 
to  a  modernization  effort  by  staffing  reengineering  roles.  MCI  had  already  created  a 
Process  Improvement  Requirements  (PIR)  Section  and  formalized  its  importance  by 
incorporating  it  into  tl;e  organizational  structure.  The  deputy  director  filled  the  role  as 
leader.  As  MCI’s  number  two  position,  the  deputy  director  is  in  the  ideal  position  to 
influence  reluctant  employees  to  embrace  the  change  program,  create  organization  vision, 
and  ensure  managerial  and  financial  continuity.  He  briefed  the  Commandant,  the 
Commanding  General,  MCCDC,  and  the  Director,  Training  and  Education  Division  to 
muster  financial  support  for  the  modernization  plan.  A  steering  committee  was  already 
formed  as  the  MCIAIS  Redesign  Team.  The  members  included  the  Deputy  Director, 
Executive  Director,  PMED  chief,  OSD  chief,  SSD  chief.  Logistics  chief,  and  the 
Computer  Systems  Analyst.  A  czar,  with  information  systems  management  experience 
and  previous  assignments  as  SSD  and  MISD  chief,  was  in  place.  Department  chief  filled 
the  role  as  process  owner.  An  external  consultant  had  been  involved  once  before  and  the 
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addition  of  the  NPS  team  provided  a  detached  perspective  as  well  as  technological 
expertise  not  possessed  by  anyone  else  in  the  MCI.  The  personnel  assigned  to  MCI  were 
ready  for  change. 

Staffing  the  reengineering  roles  outlined  above  have  the  greatest  impact  on  the 
success  of  the  reengineering  effort  at  MCI.  The  transient  nature  of  a  military  unit  makes  it 
difficult  to  sustain  long  term  projects.  Personnel  rotate  through  billets  within  a  military 
organization  every  one  to  three  years  and  not  all  of  the  personnel  rotate  at  the  same  time. 
This  staggered  rotation  lends  stability  to  long  term  projects  in  a  traditional,  non-military 
organization  by  allowing  personnel  and  policy  continuity.  However,  the  strict  hierarchical 
structure  of  a  military  unit  may  have  a  destabilizing  effect  on  long-term  projects  as  project 
teams  and  objectives  are  influenced  by  the  more  hierarchically  senior  individuals.  For 
example,  the  modernization  project  began  in  July  1995  and  significant  progress  was  made. 
In  May  1997,  a  new  deputy  director  was  assigned  and  with  modernization  well  underway, 
enthusiasm  waned.  The  new  deputy  director  is  tasked  with  other  time  consuming  duties 
and  priorities  that  prevent  him  from  continuing  the  reengineering  leadership  of  his 
predecessor.  Other  reengineering  roles  at  MCI  have  experienced  similar  dynamics. 

The  reengineenng  czar  that  began  the  project  retired  in  June  1997  and  was 
replaced  by  a  civilian  contracted  project  manager.  This  will  enhance  the  project’s  potential 
for  success  because  the  project  manager  has  military  and  database  nugration  experience 
and  is  trained  in  both  project  management  and  reengineering  techniques.  The  steering 
committee  composition  also  changed  as  members  were  replaced. 
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The  SSD  and  MISD  process  owner  are  the  only  roles  that  remained  intact 
throughout  the  research  portion  of  the  modernization  project.  The  addition  of  an  Internet 
Interface  process  owner  expected  in  August  1997  is  viewed  by  the  authors  as  a  plus  for 
the  potential  success  of  the  modernization  as  the  replacement  has  a  masters  degree  in 
Information  Technology  Management  and  is  already  familiar  with  the  MCI  modernization 
project. 

MCI  organizational  stracture  is  also  unduly  influenced  more  by  the  government 
worker  placement  policy  and  practice  than  by  sound  reengineering  principles.  In  June 
1996,  the  PIR  Section  was  formed  with  two  civilian  employees.  Their  former  MCI 
positions  were  eliminated  as  a  result  of  downsizing.  These  employees  were  transferred  to 
MCI’s  operations  department  and  chartered  to  “improve  the  MCI  process.”  Steeped  in 
TQL  tradition,  the  “process  improvement  team”  had  no  concept  of  process  modeling, 
work  flow  analysis,  or  other  techniques  necessary  to  conduct  reengineering. 

With  the  exception  of  the  project  manager,  the  process  improvement  team  and 
other  members  filling  reengineering  roles,  have  no  formal  reengineering  technique  training. 
To  ensure  project  success  at  MCI  emphasis  must  be  placed  on  filling  all  of  the  billets  on 
the  reengineering  team  with  competent  and  motivated  personnel. 

Phase  n,  understanding  the  process.  This  phase  focuses  on  data  collection  and 
modeling.  The  process  owners  had  a  thorough  understanding  of  what  their  processes  did 
and  what  they  wanted  their  processes  to  do.  The  objective  of  the  NPS  team  was  to 
document  this  awareness.  Much  of  the  data  collection  had  already  been  accomplished, 
customer  interviews,  task  breakdown  worksheets,  flow  charts,  mission  statements  and 
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models,  by  the  previous  consultant.  The  authors  believe  that  most  of  the  models  were  not 
presented  to  MCI  in  an  expected  form,  to  their  understanding  and  without  tools  for 
continued  maintenance. 

Phase  in,  streamlining.  This  phase  concentrates  on  the  reengineering  effort. 
Process  elimination  traditionally  accounts  for  a  significant  contribution  to  reengineering 
benefits.  When  applying  the  reengineering  principles  and  analyzing  the  As-Is  process 
model  looking  to  eliminate  non-value-added  processes,  it  was  discovered  that  due  to  the 
sequential  nature  of  SSD  tasks,  many  of  the  non- value-added  tasks  had  already  been 
removed.  For  example,  reporting  the  number  of  DP-37 s,  phone  calls,  or  transcript 
requests  processed  on  a  morning  report  No  one  used  this  information  and  it  was  manually 
intensive  to  collate. 

Most  processes  had  already  been  simplified.  For  example,  the  enrollment 
procedures  for  Marines  through  the  unit  diary,  and  pre-packaging  a  new  DP-37  with 
course  material  for  fascer  distribution  have  reduced  customer  response  time.  Additionally, 
SSD  functions  are  sequential  because  subsequent  tasks  depend  upon  completion  of  the 
previous  ones.  Figxire  24  illustrates  this  sequence.  As  and  example,  SSD  enrolls  students 
in  courses;  tests  their  comprehension  by  issuing  and  grading  examinations;  stores  student 
course  history;  and  issues  transcripts.  Transcripts  cannot  be  issued  without  course  history 
and  exams  cannot  be  graded  without  enrollment. 

The  remaining  reengineering  effort  had  to  focus  on  automating  manual  tasks  and 
methods  to  capture  data  only  one  time.  The  most  dramatic  impact  on  this  effort  will  be 
made  by  implementing  the  network  accessible  relational  database  technology,  MCIAIS-II. 
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Figure  24.  SSD  Sequential  Process  Flow. 


The  response  time  of  user  interaction  will  be  reduced  by  eliminating  multiple  entry 
requirements.  Graphical  user  interface  (GUI)  will  be  updated  and  more  responsive  to  user 
requirements.  The  database  itself  wiU  be  more  flexible  -  easier  to  modify  and  adjust  with 
the  more  frequent  chaiiges  commonly  encountered  in  today’s  business  environment.  A 
relational  database  provides  facilitates  flexible  query  and  customized  report  generating 
capability. 

One  method  to  take  advantage  of  a  new  relational  database  is  redistribution  of 
selected  batch  processes.  Batch  processing  is  currently  used  at  MCI  to  update  MCIAIS 
with  transactions  from  the  grading  program,  unit  diary  transactions  downloaded  from 
MCTFS,  and  input  through  daily  transactions.  Other  batch  processes  generate  transaction 
files  for  yet  other  batch  process  to  execute:  the  grading  program  creates  a  diploma  print 
file,  a  completion  certificate  file  and  an  error  listing  file;  enrollments  and  standard  material 
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requests  create  a  mailing  label  file;  another  program  creates  a  motivation  card  file.  Finally, 
there  are  batch  processes  used  to  produce  the  output  of  transaction  files:  printing  mailing 
labels  for  material  distribution,  printing  UARs  in  the  monthly  cycles,  copying  the  diploma 
file  to  disk  for  the  registrar  to  print.  These  type  of  transactions  are  necessary  because  of 
the  different  paper  stock  the  ouq)ut  requires:  mailing  labels  on  a  standard  3  Vi  inch  by  1  Vi 
inch  self-adhesive  label,  motivation  cards  and  completion  certificates  are  on  preprinted 
stock,  diplomas  require  laser  quality  print  on  heavy  gauge  stock. 

Running  the  grading  program  “on  demand,”  would  allow  SSD  greater  control  of 
their  own  schedule  and  possible  facilitate  faster  processing  of  examinations,  diplomas,  and 
error  listing.  “On  demand”  processing  could  prove  very  productive  for  the  UAR 
processing.  Over  1500  UARs  are  generated  in  the  monthly  close  out  cycle.  Responses  to 
the  UAR  are  received  over  a  short  period  of  time  and  not  much  time  is  available  to 
process  all  responses  prior  to  the  next  cycle.  The  distribution  and  response  load  could  be 
distributed  more  evenly  over  the  month.  The  SSD  clerk  would  have  more  time  for 
processing  before  the  next  cycle. 

Private  sector  businesses  rely  heavily  on  its  efficient  processing  of  customer  input. 
That  is  how  orders  are  received,  goods  are  sold  and  income  is  generated.  Not  only  are 
requests  for  enrollment  processed  through  A  single  point  of  entry,  but  also  grading 
examinations,  requests  for  materials  or  information,  and  processing  of  unit  reconciliation 
reports.  If  MCI  charged  customers  for  their  products  and  depended  on  the  processed 
payments,  using  current  procedures,  they  would  go  broke. 
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Modem  technology  has  enabled  businesses  to  cut  costs  by  moving  to  a  paper-less 
work  environment.  MCI  should  take  advantage  of  IT  to  follow  suit  A  concentrated  effort 
should  be  directed  at  utilizing  current  IT  solutions  to  replace  the  manual  tasks  involved 
with  obtaining  customer  input  by  concentrating  of  the  process  principle  of  “capture 
information  once,  at  the  sourced  Alternate  modes  of  enrollment  should  be  utilized. 
Student  services  realized  a  significant  improvement  by  enrolling  Marines  through  the  unit 
diary.  The  burden  of  data  entry  was  shifted  from  student  services  clerk  to  the  unit  diary 
clerk  and  MISD  batch  processing.  Similar  improvement  can  be  achieved  by  utilizing  the 
Internet  for  enrollmeni;,  status  query,  material  requests,  examinations,  and  changes  to 
student  information.  Many  of  the  same  processes  can  be  achieved  interactive  voice 
response  systems  (IVRS).  (Currid,  1994) 

More  efficient  processing  of  electronic  mail  can  be  realized  by  combining  a  filtering 
agent  and  establishing  standards  for  electronic  mail  sent  to  the  MCI  0MB.  Most  fiilteiing 
agents  allow  the  user  to  specify  specific  words  that  appear  in  the  “From”  or  “Subject” 
fields  of  the  e-mail.  On  that  precept,  rules  can  be  designed  to  sort  incoming  e-mail’s 
subject  line  and  distribute  to  the  appropriate  section’s  0MB  for  processing.  Subject  line 
standards  should  be  published  in  the  next  revision  of  die  Marine  Corps  Institute 
Procedures  Manual  c  r  an  MCI  Internet  Web  Page.  The  Web  Page  can  even  pre-format  the 
message  for  the  customer.  Filtering  agent  technology  is  rapidly  advancing,  such  that 
enrollments  or  queries  could  be  done  by  e-mail  and  a  response  generated  by  the  computer 
without  human  intervention.  (Currid,  1994) 
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An  Internet  based  web  page  can  used  to  publish  the  course,  the  Marine  Corps 
Institute  Procedures  Manual,  telephone  contact  directory,  as  well  as  a  Frequently  Asked 
Question  (FAQ)  library.  Customer  access  to  this  information  could  reduce  the  number  of 
telephone  calls  entertained  by  the  immediate  assist  clerks. 

Digitized  course  materials  and  electronic  distribution  upon  accepted  enrollment 
could  reduce  the  production,  warehouse  and  inventory  overhead.  This  requires  further 
analysis  of  the  available  and  required  bandwidth,  as  well  as  customer  access.  A  deployed 
Marine,  soldier,  sailor  or  airman  may  have  limited  or  no  access  to  the  Internet  or  a  PC  to 
complete  a  course  in  digitized  form. 

Development  of  a  Unit  MCI  module  that  automated  the  manual  task  of  local 
record  keeping  would  earn  praise  from  training  NCO  around  the  Marine  Corps.  Presently, 
the  training  NCO  manually  prepares  a  R-5  card  when  a  Marine  wants  to  enroll  in  a  course 
or  program.  The  form  is  forwarded  to  the  unit  diary  clerk  for  data  entry  into  MCTFS. 
Automating  the  form  such  that  it  populated  the  unit  MCI  database  and  generated  either  a 
standard  electronic  mail  or  batched  and  transmitted  to  MCI  could  b5q)ass  using  MCTFS 
and  the  unit  diary  for  enrollment.  Include  a  reconciliation  application  in  the  module  and 
UAR  could  be  done  with  minimal  human  intervention  and  improved  efficiency. 

For  those  activities  that  must  use  paper,  apply  the  process  principle:  “Perform 
work  where  it  makes  the  most  sense”  suggesting,  mail  sorting  and  segregation  could  be  left 
to  the  postal  service  prior  to  distribution  within  MCI.  Utilizing  the  last  four  digits  of  the 
nine  digit  zip  code  could  contribute  to  faster  distribution  of  incoming  mail.  Faster 
distribution  of  customer  input  translates  to  more  parallel  processing.  Automated  mail 
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handling  equipment  is  another  solution  that  could  accelerate  distribution  of  incoming  mail, 
as  well  as  capture  and  measure  the  throughput. 

Integrating  the  Logistics  Department’s  inventory  and  automating  additional 
logistics  functions  into  MCIAIS  would  improve  material  distribution  and  improve  SSD’s 
visibility  of  student  material.  The  use  of  bar-coding  can  monitor  the  progress  of  material 
through  the  packaging  and  distribution  cycle.  Shipping  status  would  become  available  to 
the  SSD  clerk  when  responding  to  student  inquiries.  Monitoring  the  distribution  cycle  can 
also  identify  other  candidates  activities  for  improvement. 

Phase  rV,  measurement  and  control.  This  phase  implements  a  system  to  control 
the  process  for  continued  improvements  (Harrington,  1991).  This  builds  on  the  process 
model  by  adding  performance  measures  for  the  reengineered  processes.  Ideally,  the 
process  modeling  technique  and  CASE  tool  selected  support  reporting  the  performance 
criteria.  DoD  and  the  FPI  methodology  emphasize  using  activity  based  costing  as  one 
measurement  method.  Additionally,  responsibility  for  model  maintenance  should  be 
established  for  continuity. 

The  PIR  Section  is  ideally  suited  for  the  responsibility  of  model  maintenance.  It  is 
staffed  by  civilian  personnel  which  is  an  uncommon  advantage  for  a  military  activity.  Such 
staffing  can  provide  necessary  continuity  to  monitor  performance.  The  personnel  are  well 
trained  in  Total  Quality  fundamentals.  They  need  additional  experience  with  process 
modeling,  process  improvement  methodology,  activity  based  costing,  and  information 
technology  opportunities.  Their  lack  of  experience  in  these  areas  detract  credibility  from 
their  assignment  in  the  PIR  Section. 


144 


The  IDEFO  modeling  technique  for  process  modeling  allows  for  representation  of 
mechanisms,  personnel,  equipment,  etc.  in  each  process.  Process  modeling  can  represent 
performance  measures.  Performance  measures  describe  the  work  done  and  the  results  of 
that  activity  (Turney,  1991).  Modeling  can  eliminate  the  seemingly  wasted  effort  in  manual 
efforts.  In  addition  to  IDEFO  modeling,  BPWin®  can  integrate  activity  based  costing 
categories  and  represent  totals  within  the  model.  Activity  based  costing  provides  two 
dimensions  to  use  in  process  reengineering:  cost  assignment  view  and  process  view. 
Together  they  can  direct  MCI  toward  a  more  efficient  product  and  service  strategy. 
Incorporating  activity  based  costing  wiU  help  MCI  realize  additional  benefits  in  process 
measurement  for  continuous  improvement  in  their  modernization  effort. 

Phase  V,  continuous  improvement.  This  phase  emphasizes  continuous  monitoring 
of  improved  processes  for  continued  excellence.  This  depends  on  maintenance  of  the 
process  models  by  monitoring  the  reengineered  processes  and  periodically  evaluating 
performance  measures.  MCI  must  develop  a  data  and  process  model,  maintain  it,  and  use 
it  for  the  benefits  the  models  provide.  Part  of  the  justification  for  migrating  from  the 
legacy  system  was  based  on  the  lack  of  code  documentation.  A  new  system  can  experience 
the  same  fate  if  not  properly  maintained.  Additionally,  the  models  enable  prototyping 
which  can  reduce  anxiety  of  implementing  changes  without  adequate  testing. 

3.  Reengineering  Summary 

Despite  the  numerous  opportunities  identified  in  the  previous  section, 
reengineering  the  As-Is  model  focused  on  migrating  the  current  functionality  to  MCIAIS- 
n.  The  lengthy  acquisition  process  and  costs  associated  with  many  of  the  IT  solutions 


145 


would  not  be  achievable  prior  to  the  expected  dehvery  of  the  new  computer.  The  objective 
shifted  to  producing  a  process  model  that  reflected  the  information  system  it  would 
immediately  represent  and  an  information  system  model  the  designers  could  use  to 
program. 

The  To-Be  process  model  did  not  include  activity  based  costing  (ABC)  because 
there  was  insufficient  data  made  available  with  which  to  model.  The  author’s  felt  that 
ABC  would  further  complicate  a  process  model,  a  concept  not  easily  appreciated  outside 
of  MISD.  There  was  already  enough  new  knowledge  required  and  a  new  costing  paradigm 
might  put  the  models  on  a  shelf  never  to  be  found. 

With  the  majority  of  processes  already  streamlined  and  non-value-added  processes 
dependent  on  automated  equipment  not  available,  reengineering  efforts  turned  to 
minimizing  redundant  data  entry,  integrating  similar  processes  and  data  sharing.  These 
three  problem  areas  are  well  suited  for  information  technology  solutions.  Specifically, 
these  three  areas  can  all  be  improved  with  implementation  of  a  relational  database 
application.  In  effect  automating  tasks  by  eliminating  the  need  to  re-key  a  customer’s  data 
when  fulfilling  multiple  requests  or  bouncing  between  screens.  Other  reengineering 
benefits  can  be  reaped  by  redistributing  and  eliminating  some  of  the  batch  processes 
performed  by  MIS.  Moving  the  functions  of  grading,  UAR  file  generation,  and  diploma 
printing  to  SSD  workstations  allow  the  user  to  execute  the  programs  “on  demand.” 

D.  TO-BE  PROCESS  MODEL  FOR  SSD 

The  To-Be  process  model  represents  the  redesigned  business  activity  of  the 

student  service  support  business  area.  It  resulted  from  reengineering  selected  processes  of 
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the  As-Is  process  model.  The  implementation  of  an  automated  information  system  based 
on  relational  database  technology,  a  dramatic  reduction  in  the  number  of  primitive  level 
processes  was  realized.  Despite  the  reduced  number  of  processes,  SSD  customer  service 
response  time  will  decrease  because  of  the  data  sharing  capability.  SSD  can  be  further 
improved  by  incorporating  a  portion  of  the  MISD  As-Is  processes  into  the  SSD  To-Be 
model.  As-Is  MISD  functions  that  could  be  mn  from  SSD  workstations  “on  demand” 
include:  the  grading  application,  UAR  file  generation,  and  diploma  printing. 

1.  To-Be  Model  Details 

All  of  the  activities  depicted  in  the  SSD  process  model  are  prefixed  with  “T.”  The 
entire  node  tree  diagram  is  too  large  to  print  as  one  document  so  it  was  divided  into 
several  diagrams  representing  various  levels.  The  remaining  model  details  must  be  gleaned 
from  careful  study  of  the  model  components  included  as  Appendix  C. 

CL  Business  Area  Decomposition 

Functional  decomposition  of  the  To-Be  model  started  at  the  business  area 
level  from  the  enterprise  analysis.  It  reconstracted  the  decomposition  of  the  As-Is  model 
using  the  reengineered  processes.  A  total  of  1 14  activities  and  120  arrows  were  identified 
and  defined.  The  business  area  Student  Service  Support  was  decomposed  six  levels  down 
to  primitive  processes  .  The  first  level  identified  four  functions:  CUSTOMER 
SERVICING,  STUDENT  ACTIVITY  SERVICING,  GRADING,  and  REGISTRAR 
SERVICING.  Figure  C-1,  Appendix  C  is  a  node  tree  diagram  of  all  the  activities  of 
Student  Service  Support. 
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The  CUSTOMER  SERVICE'JG  -  T1  function  was  decomposed  into  two 
processes:  OBTAIN  CUSTOMER  INPUT  and  PROVIDE  UNIT  ACTIVITY.  A  significant 
number  of  processes  were  reduced  by  taking  advantage  of  the  capabilities  of  the  relational 
database.  Instead  of  representing  each  different  type  of  processing  for  changing  or 
servicing  a  student’s  record,  a  CALL  arrow  was  used  to  one  of  the  processes  represented 
under  activity  T2.  The  As-Is  activity  representing  the  Conversant  AVRS  was  removed 
from  SSD  processes  and  moved  to  MISD.  Maintaining  AVRS  is  strictly  a  database 
administration  process.  Servicing  a  Marine  Corps  unit  reconciliation  processes  were 
reduced  with  the  CALL  procedure  mentioned  above  and  a  process  to  represent  the  ability 
to  request  UAR  “on  demand”  was  added. 

The  STUDENT  ACTIVITY  SERVICING  -T2  function  was  decomposed 
into  five  processes:  PROCESS  ENROLLMENT,  PROCESS  STATUS  REQUEST, 
CHANGE  STUDENT  INFORMATION,  PROCESS  ADMINISTRATIVE  ACTION  and 
PROCESS  REQUEST  FOR  MATERIAL.  All  processes  representing  a  change  input  to 
change  a  student’s  record  is  represented  in  this  function.  The  graphical  user  interface 
should  lead  the  user  to  the  desired  action  much  quicker  than  possible  in  the  As-Is  model. 
Transaction  codes  are  no  longer  required  as  most  relational  database  have  an  inherent 
transaction  code  log.  An  measurement  feature  can  be  incorporated  to  indicate  the 
student’s  mode  of  requesting  the  change  (i.e.,  telephone,  e-mail,  walk-in,  UAR,  etc.). 
Material  request  processing  was  automated  by  eliminating  the  use  of  manual  forms  for 
“Request  for  Material”  and  “Off-line  Material”  requests.  Routing  for  approval  can  be 
accomplished  by  the  DBMS  application  if  stiU  required. 
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The  GRADING  -T3  function  was  decomposed  into  four  functions: 
PROCESS  DP-37’ S,  PROCESS  HAND  GRADED  EXAMS,  RUN  GRADING 
PROGRAMS  and  PROCESS  OPSCAN  ERRORS.  This  process  stUl  has  a  lot  of  manual 
processes  represented.  The  OCR  readable  exams  issued  and  the  two  different  sized  forms 
was  a  limiting  factor.  An  “on  demand”  process  was  added  to  facilitate  running  the 
program  to  grade  exams  data  collected  from  the  scanned  DP-37s.  The  “on  demand” 
facility  provides  an  added  feature  to  work  the  OPSCAN  error  listing  “on  demand”  as  weU. 

The  REGISTRAR  SERVICING  -  T4  function  was  decomposed  into  two 
functions:  ISSUE  DIPLOMA  and  ISSUE  TRANSCRIPT.  An  “on  demand”  feature  was 
added  to  allow  the  user  to  print  diplomas  at  any  time  following  the  execution  of  the 
grading  program.  The  transcript  production  reflects  automated  transcript  generation  based 
on  user  provided  information  for  the  transcripts  requested  by  former  students  whose  data 
has  been  archived  on  microfiche.  The  transcript  application  would  be  programmed  to  draw 
all  student  information  from  MCIAIS  to  complete  a  transcript  from  an  internal  template. 

b.  To-Be  Process  Model 

The  To-Be  process  model  documents  the  business  system  model  for  the 
new  information  system  of  MCI.  Graphic  representations  helped  to  summarize  the  result. 
The  To-Be  process  model  consists  of  a  functional  decomposition  diagram  (Table  C-2, 
Appendix  C),  an  activity  dictionary  (Table  C-3,  Appendix  C),  an  arrow  dictionary  (Table 
C-4,  Appendix  C),  the  node  tree  diagram  (Figure  C-1,  Appendix  C),  the  context  diagram 
(Figure  C-2,  Appendix  C)  and  an  IDEFO  kit  (Figures  C-3  -  C-37,  Appendix  C)  presenting 
the  process  decomposition  down  to  the  primitive  levels. 
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Not  all  of  the  manual  activities  could  be  eliminated.  They  remain  in  the 
process  model  to  provide  complete  definition  to  the  business  system  architecture.  Future 
continuous  improvement  efforts  should  focus  on  reengineering  principles  to  further  reduce 
their  persistence  and  increase  process  efficiency.  Additionally,  shifting  to  a  process 
improvement  oriented  accounting  approach,  such  as  activity  based  costing,  would  help 
realize  the  true  cost  of  delaying  further  process  improvements. 

2.  Information  System  Model 

The  SSD  information  system  model  represents  what  data  the  system  manipulates, 
captures,  and  stores  in  the  MCI  To-Be  process  model.  While  this  thesis  focuses  on  the 
first  two  stages  of  the  information  engineering  methodology,  a  proof-of-concept  prototype 
is  an  objective  of  the  MCI  modernization  project.  Design  and  construction  of  the 
information  model  is  beyond  the  scope  of  this  thesis,  however,  information  system 
prototype  development  requires  a  different  view  of  the  data  and  process  models.  As  a 
result,  an  information  model  was  developed  to  facilitate  prototype  development.  As  noted 
in  Chapter  V,  there  ace  three  parts  to  the  model:  (1)  DFDs  depicting  information  system 
process  decomposition,  (2)  definitions  of  all  of  the  symbols  on  each  of  the  diagrams,  and 
(3)  process  specifications  at  the  primitive  process  level.  The  information  system  model 
serves  as  a  bridge  between  the  data  and  process  modelers  and  the  prototype  developer. 
a.  DFDs 

As  noted  in  Chapter  V,  the  first  step  in  developing  an  information  model  is 
to  remove  the  manual  processes  from  the  To-Be  model.  The  SSD  system  context  diagram. 
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shown  in  Figure  25,  shows  the  SSD  System  and  the  outside  entities.  A  context  diagram  is 
the  highest  level  of  the  DFD. 


MCCTA 


DO  Input 


MCTFS  Marine 
Information 


UD  Output 


Course,  Program  & 
Logistics  Information 


SSD  SYSTEM 


-Material,  Course/Program  Status 


MCI 

Departments 


MCI  Customer 


Invoice  Data 


Customer  Information  ■ 
Customer  Request 


Figure  25.  SSD  System  DFD:  Context  Diagram. 

Functional  decomposition  techniques,  described  in  Chapter  V,  are  applied 
to  the  context  diagram  to  create  the  next  level  of  the  DFD,  diagram  0.  Figure  26  shows 
the  five  major  automated  processes  of  the  SSD  information  system  model:  (P-IP)  Display 
Catalog,  (P-2P)  Update  Marine  Information,  (P-3P)  Interface  with  Unit  Diary,  (P-4) 

Order  Material,  and  (P-5)  Service  Student.  Each  of  these  processes  is  further  decomposed 
to  the  primitive  level.  The  prototype  developer  uses  these  diagram  in  conjunction  with  the 
symbol  dictionary  and  process  specifications  to  code  the  protot5q)e. 

All  of  the  processes  hierarchy  numbers  depicted  in  the  SSD  information 
system  model  are  prefixed  with  “P”  for  process.  All  of  the  data  store  hierarchy  numbers 


depicted  in  the  SSD  information  system  model  are  prefixed  with  “D”  for  data  store.  The 
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Figure  26.  SSD  System  DFD:  Diagram  0. 
suffix  “P”  indicates  primitive  level  processes.  Figures  27  and  28  illustrate  two  of  the 
primitive  level  DFD  diagrams  for  the  SSD  processes  illustrating  DFD  techniques.  The 
remaining  decomposition  diagrams  are  too  large  for  inclusion  in  this  thesis  but  may  be 
viewed  in  NPS-SM-97-006:  Analysis,  Design,  and  Prototype  Implementation  of  a 
Contemporary  Information  System  for  the  Marine  Corps  Institute,  Final  Report  (Kamel 
et  al.,  1997). 

Data  stores  are  also  decomposed  in  a  way  similar  to  processes.  The 
technique  was  devised  to  aid  developers  and  analysts  working  with  large  numbers  of 
database  tables.  The  same  parent/child  relationships  that  apply  to  processes  also  apply  to 
data  stores  and  its  use  prevents  cluttered  and  confusing  diagrams.  Figure  29  shows  how 
the  SSD  database,  MCIAIS-2,  is  decomposed  into  subordinate  data  stores.  This  first 
subordinate  decomposition  diagram  is  a  logical  grouping  of  data  entities.  Decomposition 
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Figxire  27.  SSD  System  DFD:  (P-IP)  Display  Catalog. 


UD  Acknowledgment 


Figure  28.  SSD  System  DFD:  (P-5.9.3P)  Determine  Pass/FaU. 
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Figure  29.  MCIAIS-2  Data  Store  Decomposition, 
continues  until  actual  data  model  table  names  are  identified  and  assigned  a  hierarchy 
number.  Figure  30  illustrates  how  the  logical  data  store  (D-1.4)  Logical  Student  History  is 
decomposed  further  into  five  actual  database  tables:  (D- 1.4.1)  STUD_CRS_EXAM_X, 
(D-1.4.2)  STUD_CRS_X, :  (D-1.4.3)  STUD_PRG_X, :  (D-1.4.4), 

STUD_CRS_TRAN_  X  (D- 1.4.5)  STUD_PRG_TRAN_X. 
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Figure  30.  SSD  System  DFD:  (D-1.4)  Logical  Student  History  Data  Store 


Decomposition. 


b.  DFD  Symbol  Dictionary 


The  DFD  decomposition  diagrams  are  accompanied  by  the  DFD  symbol 


dictionary.  Without  the  dictionary,  it  is  difficult  for  a  prototype  developer  to  distinguish 
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data  table  names  witli  the  precision  necessary  to  code  the  prototype.  For  example,  two 
data  table  names  in  the  data  model  are  ERR_CODES  and  ERR_LIST  Although  the  be 
names  may  be  distinctive  to  the  data  modeler,  implementation  coding  and  debugging  may 
frustrating  to  the  programmer  because  a  data  element  may  be  coded  to  read  from  the 
incorrect  data  table. 

The  DFD  symbol  dictionary  is  arranged  alphabetically  and  contains  an 
entry  for  each  of  the  214  symbols  that  appear  in  the  diagrams.  Each  page  of  the  dictionary 
contains  colurrmar  headings  for  symbol  name  and  hierarchical  number  (data  flows  are  not 
assigned  a  number),  type  of  S5unbol,  description,  and  the  DFD  diagram  number  where 
the  symbol  appears.  In  addition  to  alphabetical  appearance,  font  type  and  size  is  used  as  to 
further  aid  dictionar>  use.  Processes  are  listed  in  all  capital  letters,  and  data  flow  are  listed 
in  ten  pitch  title  case.  Figure  31  is  an  excerpt  from  the  dictionary.  The  entire  dictionary 
may  be  viewed  in  NPS-SM-97-006:  Analysis,  Design,  and  Prototype  Implementation  of 
a  Contemporary  Information  System  for  the  Marine  Corps  Institute,  Final  Report  (Kamel 
et  al.,  1997). 

c.  Process  Specifications 

Process  specifications  summarize  the  data  input,  output,  and  logic  of  each 
of  the  primitive  processes.  Only  primitive  level  processes  are  included  as  parent  processes 
are  an  aggregated  collection  of  the  children's  inputs,  outputs,  and  logic.  A  typical  process 
specification  for  a  primitive  level  process  is  shown  in  Figure  32.  Process  specifications  for 
entire  model  may  be  viewed  in  NPS-SM-97-006:  Analysis,  Design,  and  Prototype 
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DFD  Symbol  Dictionary 


Name  Symbol  Type  Definition 


DFD 


CrsOnHandQty 

Data  Flow 

Data  element  definitions  can  be  found  in  the 

Attribute  Definitions  Report  (Exhibit  5,  Appendix  A) 

P-4.4P 

Current  Course  Request 

Data  Flow 

Course  requested:  that  is  current  version 

P-5.10. IP 

P-5.1 0.2P 

Current  Program  Request 

Data  Flow 

Program  requested:  that  is  current  version 

P-5.10.1P 

P-5.1 0.2P 

CUST  (D>1.5.1) 

Data  Store 

CustSSn_ID  +  State  +  CustLastName  + 
CustFirstName  +  CustMidInit  +  CustDSN  + 
CustCommNo  +  CustAddrI  +  CustAddr2  +  CustCity 
+  CustZip 

D-1.5 

P-4.1  P 

P-4.2P 

Customer  Identity 

Data  Flow 

Customer  Instance 

P-4.1  P 

P-4.2P 

P-4.3P 

Customer  Information 

Data  Flow 

Name,  rank,  SSN,  grade,  service  component, 
address,  and  telephone  number. 

context 

P-0 

P-4.2P 

Customer  Instance 

Data  Flow 

CustSSn_ID  +  State  -i-  CustLastName 

CustFirstName  +  CustMidInit  +  CustDSN  + 
CustCommNo  +  CustAddrI  +  CustAddr2  +  CustCity 
+  CustZip 

P-4.1P 

P-4.2P 

Customer  Order 

Information 

Data  Flow 

Customer  Information  +  Material  Request  -i-  Invoice 
Data 

P-0 

Customer  Request 

High  level  bundle  of  inquiries  or  other  requests  from 
a  customer:  status,  information,  transcript  request, 
request  for  material,  etc. 

context 

Customer  SSN 

Data  Flow 

SSN  of  customer 

P-4.1P 

DETERMINE  IF  STUDENT 
MEETS  PREREQUISITES 
(P-5.10.3P) 

Process 

Compares  the  requested  course  or  program 
prerequistes  to  the  student's  course  history. 

P-5.10 

DETERMINE  OF 

STUDENT  IS  IN  DATA 
BASE  (P-5. IP) 

Process 

Checks  for  SSN  match  to  a  student  SSN  in  the  MCI 
student  data  base. 

P-5 

DETERMINE  PASS/FAIL 
(P-5.9.3P) 

Process 

Compares  number  student’s  exam  correct  answers 
to  the  minimum  passing  score  for  that  exam. 

P-5.9 

Diploma 

Data  Flow 

The  certificate  issued  to  the  student  for  passing  all 
of  the  course  exams  that  make  up  a  program.  The 
diploma  is  accompanied  by  a  letter  indicating 
transript  information  for  the  program  and  summary 
of  the  included  courses. 

P-5.9 

P-5.9.6P 

DISENROLL  STUDENT 
(P-5.6P) 

Process 

Disenrolls  a  student  from  a  course  he/she  is  enrolled 
in 

P-5 

DIsenrolled 

Data  Flow 

Data  element  definitions  can  be  found  in  the 

Attribute  Definitions  Report  (Exhibit  5,  Appendix  A) 

P-5.6P 

Data  element  definitions  can  be  found  In 

the  Attribute  Definitions  Report  SSD  Process  Model 

(Exhibit  5,  Appendix  A)  Exhibit  28,  Appendix  B 
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Figure  31.  Excerpt  From  DFD  Symbol  Dictionary. 


Process  Specification  Form 
Process  Nimber:  P-5.9.6P 
Process  Name:  print  diploma 
Input  Data  Flow: 

Program  Completion  Information 
Student  Identity 
AD  Marine  Student  Address 
Marine  Reservist  Address 
NonMarine  Student  Address 
Output  Data  Flow: 

Diploma 
Invoice  Instance 
PrgDipIssueDate 
TranJD  +  SP_TransDate_ID 
Module  Logic: 

For  each  program  completion 
GET  Student  Identity 

appropriate  address 

UPDATE  Student  Program  History 
CREATE  Invoice  Instance 

FORMAT  &  PRINT  Diploma  _ 

Figure  32.  Process  Specification  Form  for  (P-5.9.6P)  Print  Diploma. 

Implementation  of  a  Contemporary  Information  System  for  the  Marine  Corps  Institute, 

Final  Report  (Kamel  et  al.,  1997). 

3.  Application  Mapping 

A  Process  versus  Data  Entity  (CRUD)  Matrix  was  developed  from  the  To-Be 
process  model.  The  CRUD  Matrix  maps  the  process  activities  to  the  data  base  tables  and 
is  included  as  Figure  C-38  of  Appendix  C.  The  CRUD  Matrix  validates:  1)  that  all  of  the 
data  model  entities  have  a  purpose  in  the  process  model,  and  2)  that  the  data  model 
contains  only  the  entities  required  by  the  process  model. 

Clustering  the  CRUD  Matrix  results  in  the  Clustered  CR  Matrix.  Every  “C’,  “U”, 
and  “D”  was  replaced  with  a  “C”  as  described  in  Chapter  HI.  BPWin®  did  not  perform  an 
automated  clustering.  A  manual  procedure  was  necessary.  All  of  the  BPWin  entities 
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representing  transient  data  created  in  the  process  model  were  removed  from  the  CRUD 
Matrix.  All  of  the  manual  processes  were  also  removed  as  well  since  there  was  not  a  data 
entity  with  which  to  associate.  The  remaining  relationships  were  arranged  to  form  groups. 

Analysis  of  the  groupings  that  result  from  the  Clustered  CR  Matrix  reveal  four 
SSD  applications:  Student  Servicing,  Unit  Servicing,  Grading,  and  Registrar.  A  fifth 
application.  Executive  Sunnmary  Information,  was  identified  to  provide  management  with 
the  adhoc  query  capability  achievable  with  a  relational  database.  The  logical  and  physical 
distribution  of  the  five  applications  throughout  SSD  is  described  in  another  team  members 
thesis  (Evers,  Jr.,  1997).  The  CR  Matrix  is  included  as  Figure  C-39,  Appendix  C.  Table  5, 
details  the  capability  of  each  of  the  applications. 


Application 

Capability 

Student  Servicing 

On-line  Course  Catalog  Access,  Enrollment,  Diseraollment, 
Course  History  Access,  Order  Materials 

Unit  Servicing 

On-line  Course  Catalog  Access,  Enrollment,  DisenroUment, 
Course  History  Access,  Order  Materials ,  UAR  Generation 

Grading 

Grading,  Course  History,  Student  History 

Registrar 

On-line  Course  Catalog  Access,  Course  History,  Transcript 
Generation 

Executive  Summary 
Information 

On-line  Course  Catalog  Access,  Predefined  SQL  Query 
Capability 

T  able  5.  Recommended  Application  Capability. 
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Vin.  SUMMARY,  RECOMMENDATIONS,  AND  CONCLUSIONS 
This  chapter  provides  a  summary  of  the  thesis  as  well  as  recommendations  and 
conclusions.  First  it  addresses  the  research  questions  and  objectives  presented  in  Chapter 
1.  Next  it  summarizes  the  enterprise  analysis  methodology,  process  modeling,  and  a 
recommended  reengineering  plan  for  the  Student  Services  Department  at  MCI. 
Additionally,  it  includes  implementation  recommendations  and  some  anticipated  obstacles. 
The  chapter  concludes  with  suggested  topics  for  future  study  and  conclusions. 

A.  ACHIEVEMENT  OF  RESEARCH  OBJECTIVES  AND  QUESTIONS 

This  research  is  the  result  of  a  year  long  project  commissioned  by  MCI  to  develop 
the  architecture  and  supporting  migration  plan  to  transition  from  a  closed,  non-relational 
system  to  an  open,  client/server  based  relational  database  management  system  (DBMS). 
The  research  and  development  was  conducted  by  a  six  member  team  at  the  Naval 
Postgraduate  School.  The  objectives  of  this  research  project  were  achieved;  enterprise 
analysis  was  conducted,  business  area  analysis  of  the  SSD  was  conducted,  data  and 
process  models  were  developed,  the  process  model  was  reengineered,  an  information 
system  was  designed  and,  a  proof  of  concept  prototype  was  produced.  If  implemented,  the 
modernization  plan  will  make  the  SSD  more  efficient  and  effective  at  providing  service  to 
their  customers. 

In  the  course  of  this  project,  the  research  questions  posed  in  Chapter  I  were 

answered.  These  questions  and  their  answers  are  outlined  below. 

•  Can  a  process  model  be  developed  to  reflect  the  current  business  process  of 
the  Student  Services  Department  of  the  Marine  Corps  Institute  (MCI)? 


161 


A  detailed  As-Is  process  model  was  created  using  IDEFO  modeling  techniques  for 
the  Student  Services  Department  of  MCI.  The  model  diagrams  and  the  data  dictionary  are 
included  in  NFS  Technical  Report  NPS-SM-97-006:  Analysis,  Design,  and  Prototype 
Implementation  of  a  Contemporary  Information  System  for  the  Marine  Corps  Institute, 
Final  Report  (Kamel  et  al.,  1997).  The  model  conforms  to  the  DoD  standard  for  process 
modeling  and  can  serv  e  as  a  baseline  process  model  for  future  reengineering  efforts. 

•  Can  the  business  process  of  the  Student  Services  Department  of  MCI  be 
reengineered? 

The  SSD  business  process  can  only  be  reengineered  to  a  limited  extent  due  to  the 
nature  of  MCI  work  flow  as  well  as  budgetary  constraints.  There  are  no  tasks  in  the  SSD 
process  that  can  be  eliminated  because  of  the  sequential  nature  of  the  SSD  work  flow. 
However,  reengineering  benefits  can  be  gained  from  implementation  of  a  shared  relational 
database  that  eliminates  redundant  data  entry,  publication  of  the  course  catalog  on  the 
Internet,  and  development  of  on-line  enrollment  forms  to  further  increase  the  efficiency 
and  effectiveness  of  ifie  Student  Services  Department. 

•  Can  a  process  model  be  developed  to  reflect  the  reengineered  business  process 
of  the  Student  Services  Department  of  MCI? 

A  To-Be  process  model  was  created  using  IDEFO  modeling  techniques  for  the 
Student  Services  Department  of  MCI.  The  model  diagrams  and  the  data  dictionary  are 
included  in  NFS  Technical  Report  NFS-SM-97-006:  Analysis,  Design,  and  Prototype 
Implementation  of  a  Contemporary  Information  System  for  the  Marine  Corps  Institute, 
Final  Report  (Kamel  et  al.,  1997).  The  model  conforms  to  the  DoD  standard  for  process 
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modeling  and  can  serve  MCI  as  an  example  and  first  iteration  of  an  ongoing  reengineering 
effort. 

•  What  BPP.  methodology  is  most  suitable  for  reengineering  the  Student 
Services  Department  of  MCI? 

Of  the  four  BPR  methodologies  surveyed,  Hammer  and  Champy’s  Business 
Process  Reengineering,  Thomas  Davenport’s  Process  Innovation,  H.  James  Harrington’s 
Business  Process  Improvement,  and  DoD’s  Functional  Process  Improvement  (FPI),  no 
one  methodology  was  identified  as  a  perfect  fit  for  reengineering  the  SSD.  Each 
methodology  has  strengths  and  weaknesses  that  effect  its  use  in  the  MCI  business 
environment.  Elements  of  all  four  methodologies  were  applied  with  particular  emphasis  on 
the  business  process  improvement  methodology  of  H.  J.  Harrington. 

•  What  CASE  tool  is  most  suitable  for  reengineering  the  Student  Services 
Department  of  MCI? 

Although  BPwin®  was  the  CASE  tool  selected  and  used  for  process  modeling. 
System  Architecf(BPK  Professional  would  have  been  a  better  choice  because  it  offered 
one  central  repository  for  both  data  and  process  model  metadata  and  a  more  versatile 
DFD  graphics  capability.  Despite  the  advertised  compatibility  of  BPwin®  with  its  sibling 
data  modeling  tool  ERwin®,  initial  metadata  transfer  between  the  two  tools  was  less  than 
perfect.  During  the  course  of  the  project,  it  was  necessary  to  request  a  software  patch 
from  the  vendor  so  that  data  model  definitions  could  be  imported  into  BPwin®. 

•  Can  a  CRUD  diagram  be  developed  to  support  the  BPR  of  the  Student 
Services  Department  of  MCI? 

A  CRUD  matrix  for  the  SSD  was  generated  and  clustered.  The  CRUD  matrix, 
containing  44  data  entities  and  113  functional  activities  was  clustered  manually  because 
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none  of  the  reviewed  CASE  tools  had  that  capability.  BPwin®  did  have  a  CRUD  matrix 
module  that  generated  the  CRUD  matrix  on  a  Microsoft  Excel  spreadsheet  but  needed  to 
be  refined  and  adjusted  manually  because  of  the  model’s  large  size. 

B.  SUMMARY  OF  PROCESS  MODEL  DEVELOPMENT 

Process  model  development  was  conducted  according  to  the  first  two  stages  of 

James  Martin’s  information  engineering  methodology:  enterprise  level  analysis  and 
business  area  analysis.  Within  these  two  stages,  information  about  the  organization  is 
gathered  and  analyzed  with  matrices  and  diagrams  to  produce  an  As-Is  model.  The  As-Is 
model  is  then  reengineered  to  produce  the  To-Be  model.  The  DoD  standard  IDEFO 
modeling  technique  is  used  for  both  process  models.  This  process  takes  some  time  to 
complete  but  ensures  sufficient  detail  for  sound  analysis. 

C.  IMPLEMENTATION  RECOMMENDATIONS 

The  following  recommendations  are  suggested  for  reengineering  implementation  at 

MCI. 


•  Examine  the  set  of  high  level  matrices  developed  in  this  study  that  show  the 
relationship  between  entities,  functions,  organization  units  and  locations.  Use 
the  inforn.ation  obtained  from  the  matrices  to  review  the  mission,  functions, 
goals,  organization  structure,  and  the  information  needed  to  run  MCI  business. 

•  View  reengineering  at  MCI  as  an  ongoing  effort  and  supported  by  the 
information  systems  architectures,  methodologies  and  tools. 

•  Establish  a  priority  and  schedule  for  developing,  refining,  and  reengineering  the 
business  area  process,  beyond  the  student  services  functions,  according  to  the 
business  areas  identified  in  this  study. 

•  Utilize  a  single  database  to  facilitate  data  sharing  among  MCI  departments, 
streamline  processes,  facilitate  automation,  eliminate  data  redundancy,  and 
improve  customer  service. 
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•  Utilize  Activity  Based  Costing  (ABC)  methodology  to  identify  cost  drivers  in 
SSD.  Like  most  DoD  activities,  capturing  and  distributing  cost  data  is  not  a 
common  practice. 

•  Facilitate  further  SSD  reengineering  with  the  development  and  collection  of 
measures  of  effectiveness  (MOE)  and  measures  of  performance  (MOP). 
Properly  chosen  MOPs  and  MOEs  are  critical  to  the  evaluation  of  process 
improvements  and  will  help  identify  other  candidate  processes  for 
improvement 

•  Consider  the  development  of  a  Training  NCO  Interface  Application.  This 
application  would  essentially  manage  the  Training  NCO’s  R-5  file  on  a  local 
database  and  would  reduce  manual  data  input  for  the  new  system. 

D.  ANTICIPATED  OBSTACLES 

Organizational  issues  such  as  fiscal  limitations,  politics,  cultural  bias,  and  top-level 
leadership  support  must  be  considered.  IS  managers  must  be  able  to  face  these  challenges 
effectively,  or  the  technical  issues  discussed  in  this  work  will  have  little  impact  on  the 
success  of  future  system  deplojmrient.  These  issues  are  beyond  the  scope  of  this  thesis. 

E.  FUTURE  RESEARCH  REQUIREMENTS 

Many  informr  tion  technology  solutions  have  reengineering  applicability  to  the 
business  areas  at  MCI.  However,  before  they  are  blindly  applied,  a  thorough  business  area 
analysis,  similar  to  the  one  conducted  in  this  thesis  on  the  Student  Services  Department, 
must  be  conducted  on  each  of  the  remaining  business  areas.  The  two  business  areas  with 
the  most  interaction  with  SSD  are  the  logistics  and  the  program  and  course  development 
departments. 

F.  CONCLUSIONS 

To  deploy  and  operate  effectively  and  efficiently  in  the  information  age,  DoD 
organizations  must  take  a  serious  look  at  the  way  they  conduct  business  and  implement 
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their  processes.  A  defuiled  process  analysis  of  a  business  area  provides  an  opportunity  for 
redesigning/reengineesing  to  reduce  costs,  improve  efficiency,  and  better  meet  the  needs 
of  customers.  The  de  /elopment  of  an  enterprise  wide  model  and  detailed  data  and  process 
business  area  models  are  the  necessary  building  blocks  for  developing  and  deploying 
information  systems  that  support  the  mission  and  objectives  of  the  organization. 

Adopting  a  methodology  based  on  the  development  of  the  three  models 
(business/process,  data  and  technology)  is  extremely  important  for  successful  redesign  at 
both  enterprise  and  business  application  area  levels.  The  development  of  a  detailed  As-Is 
business  process  model  is  necessary  to  thoroughly  understand  the  processes  of  the 
different  departments  of  MCI  and  for  successful  reengineering.  There  are  a  variety  of 
modeling  techniques  available,  as  weU  as  numerous  CASE  tools  which  support  these 
models.  Managers  fc.ce  the  dilemma  of  which  tools  and  strategies  to  select  when  dealing 
with  the  migration  fro  n  legacy  systems  to  open,  relational  information  systems.  This 
research  supports  the  use  of  an  information  engineering  methodology  coupled  with  IDEE 
modeling  techniques  and  a  suitable  CASE  tool  which  supports  synchronization  of  process 
and  data  models.  This  approach  will  allow  for  successful  migration  to  open,  client/server 
information  systems. 
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APPENDIX  A.  BPR  METHODOLOGIES 


This  appendix  contains  details  of  the  business  process  reengineering  methodologies  discussed  in 
Chapter  III. 

a.  Hammer ,  Champy,  and  Stanton 

For  more  information  consult  the  following  books: 

Michael  Hammer,  James  Champy,  Reengineering  the  Corporation  :  A  Manifesto  for  Business  Revolution, 
HaiperBusiness,  New  York:  1994. 


Michael  Hammer,  Steven  A.  Stanton,  The  Reengineering  Revolution  :  A  Handbook,  HaiperBusiness,  New 
York:  1995. 


b,  Thomas  Davenport 

From  Thomas  H.  Davenport,  Process  Innovation:  Reengineering  Work  through  Information 

Technology,  Harvard  Business  School  Press,  Boston:  1993. 

Davenport’s  Five  Phases  of  Process  Innovation 

PHASE  I:  IDENTIFY  PROCESSES  FOR  INNOVATION 

Key  activities:  -Enumerate  major  processes 

-Detemiine  process  boundaries 
-Assess  strategic  relevance  of  each  process 
-Render  high-level  judgements  of  the  “health”  of  each  process 
-Qualil  v  the  culture  and  politics  of  each  process 

PHASE  II:  IDENTIFY  CHANGE  LEVERS 

Key  activities:  -Identify  potential  technological  and  human  opportunities  for  process  change 
-Identify  potentially  constraining  technological  and  human  factors 
-Research  opportunities  in  terms  of  application  to  specific  processes 
-Determine  which  constraints  will  be  accepted 

PHASE  III:  DEVELOP  PROCESS  VISION 

Key  activities:  -Assess  existing  business  strategy  for  process  directions 

-Consult  with  process  customers  for  performance  objectives 
-Benchmark  for  process  performance  targets  and  examples  of  innovation 
-Formulate  process  performance  objectives 
-Develop  specific  process  attributes 

PHASE  IV:  UNDERSTAND  EXISTING  PROCESSES 

Key  activities:  -Describe  the  current  process  flow 

-Measure  the  process  in  terms  of  the  new  process  objectives 
-Assess  the  process  in  terms  of  the  new  process  attributes 
-Identify  problems  with  or  shortcomings  of  the  process 
-Identify  short-term  improvements  in  the  process 
-Assess  current  information  technology  and  organization 
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PHASE  V:  DESIGN  AND  PROTOTYPE  THE  NEW  PROCESS 
Key  activities:  -Brainstorm  design  alternatives 

-Assess  feasibility,  risk,  and  benefit  of  design  alternatives  and  select  the  preferred 
process  design 

-Prototype  the  new  process  design 

-Develop  a  migration  strategy 

-Implement  new  organizational  structures  and  systems 

c.  H*  James  Harrington 

From  H.  James  Harrington,  Business  Process  Improvement:  The  Breakthrough  Strategy  for 
Total  Quality,  Productivity,  and  Competitiveness,  McGraw-Hill,  Inc.:  New  York,  1991. 


Harrington's  Five  Phases  of  Business  Process  Imnrovement  (BPI) 


PHASE  I:  ORGANIZING  FOR  IMPROVEMENT 

Objective:  To  ensure  success  by  building  leadership,  understanding,  and  commitment 
Activities:  1.  Establish  Executive  Improvement  Team  (EIT) 

2.  Appoint  a  business  process  improvement  (BPI)  champion 

3.  Provide  executive  training 

4.  Deveiop  an  improvement  model 

5.  Communicate  goals  to  employees 

6.  Review  business  strategy  and  customer  requirements 

7.  Select  the  critical  process 

8.  Appoint  process  owners 

9.  Select  the  process  improvement  team  (PIT) 


PHASE  II:  UNDERSTANDING  THE  PROCESS 

Objective:  To  imderstand  all  the  dimensions  of  the  current  business  process 

Activities:  1.  Define  the  process  scope  and  mission 

2.  Define  process  boundaries 

3.  Provide  team  training 

4.  Develop  a  process  overview 

5.  Define  customer  and  business  measurements  and  expectations  for  the  process 

6.  Row  diagram  the  process 

7.  Collect  cost,  time,  and  value  data 

8.  Perform  process  walk-throughs 

9.  Resolve  differences 

10.  Update  process  documentation 


PHASE  III:  STREAMl^INING 

Objective:  To  improve  tne  efficiency,  effectiveness,  and  adaptability  of  the  business  process 
Activities:  1.  Provide  team  training 

2.  Identify  improvement  opportunities: 

Errors  and  rework  High  cost 

Poor  quality  Long  time  delays 

Backlog 

3.  Eliminate  bureaucracy 

4.  Eliminate  no-value-added  activities 


5.  Simplify  the  process 

6.  Reduce  process  time 

7.  Error-proof  the  process 

8.  Upgrade  equipment 
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9.  Standardize 

10.  Automate 

11.  Document  the  process 

12.  Select  the  employees 

13.  Train  the  employees 

PHASE  IV:  MEASUREMENT  AND  CONTROL 

Objective:  To  implement  a  system  to  control  the  process  for  ongoing  improvement 

Activities:  1.  Develop  in-process  measurements  and  targets 

2.  Establish  a  feedback  system 

3.  Audit  the  process  periodically 

4.  Establish  a  poor-quality  cost  system 

PHASE  V:  CONTINUOUS  IMPROVEMENT 
Objective:  implement  a  continuous  improvement  process 
Activities:  1.  Qualify  the  process 

2.  Perform  periodic  qualification  reviews 

3.  Define  and  eliminate  process  problems 

4.  Evaitiate  the  change  impact  on  the  business  and  on  customers 

5.  Benchmark  the  process 

6.  Provide  advanced  team  training 


d.  DoD  Functional  Process  Improvement  (FPI) 

From  DoDInst  8020.  IM 

A  25-step  methodology  has  been  developed  that  will  take  an  FPI  project  team  from  developing  a  strategic 
plan  to  the  development  of  a  final  functional  economic  analysis  (FEA)  or  business  case.  It  is  important  to 
note  that  an  organization  may  have  already  completed  some  of  the  steps  of  the  methodology  through  other 
means  such  as  Total  Quality  Management  (TQM)  initiatives  or  an  Information  Systems  Planning  GSP) 
effort.  The  information  generated  as  a  result  of  these  efforts  will  greatly  reduce  the  amount  of  time 
necessary  to  complete  the  FPI  project. 

Strategic  Planning  (Steps  1-4) 

1.  Secure  Executive  Commitment  for  Functional  Process  Improvement  Project 

-Conduct  executive  briefings 

-  Concepts  and  principles  of  FPI 

-  DoD  policy  and  requirements 

-  Functional  management  process  (DoD  8020. 1-M,  Ch  2) 

-  FPI  Management  Framework 

-  Intended  expected  benefits 

-  Proje:>t  management  considerations 

-Arrange  site  visits  to  organizations  committed  to  TQM/FPI 
-Develop  Charter  defining  scope  and  extent  of  project 
-Secure  explicit  commitment  to  launch  project 

2.  Confirm/Define  Functional  Mission 

-identify  higher  authority  mandates/constraints 

-  Review  DoD  relevant  policy 

-  Review  applicable  DoD  directives  (8000  series) 

-  Review  DMRD  requirements/constraints 
-Identify  current  resource  availability 
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-Develop  statement  of  values  and  beliefs 

-Develop  mission  statement 

-Test  mission  statement  for  consistency  and  efficacy 

-  Mission  statement  is  consistent  with  higher  authority  mandates/constraints 

-  Mission  statement  can  be  accomplished  with  current  resource  availability 

-  Mission  statement  embodies  stated  values  and  beliefs 

3.  Develop  Strategic  Plai^ 

-Identify  functicjrtal  Customers 

-  External 

-  Internal 

-Establish  critical  customer  requirements  and  needs 

-  Analysis  of  current  service  levels 

-  Customer  surveys  and  interviews 

-  Value-chain  analysis  (customer  products  and  services) 

-Prioritized  customer  requirements  and  needs 

-Identify/rank  current  and  potential  competitors  (alternative  sources) 

-Test  customer  requirements  and  needs  against  mission  statement 
-Resolve  mission/customer  requirements  and  needs  inconsistencies 
-Develop  prioritized  list  of  customer  requirements  that  will  be  met 
-Develop  functional  goals  for  satisfying  customer  requirements 

-  Develop  vision  statement  (Guiding  Principle(s)) 

-  Identify  goals  for  key  results  areas 

-  Customer  satisfaction 

-  Productivity 

-  Innovation 

-  Resource  conservation 

-  Management  development  and  performance 

-  Employee  development  and  performance 

-  Public  responsibility 

-  Develop  critical  success  factors 
-Test  goals  stater  lents  against  mission,  values  and  beliefs 

4.  Conduct  Strategic/Customer  Benchmarking  and  Best  Practices  Analysis 

-Conduct  Competitive  analysis 
-Examine  available  benchmarking  databases 
-Interview  customers 
-Interview  functional  area  experts 
-Research  literature 

-Validate  goals  statements  against  benchmarking  best  practices  data 
-Refine  statement  of  goals 


Business  Planning  (Steps  5-81 


5.  Develop  Business  Plan 

-Develop  measiirements  for  each  stated  goal 

-Identify  product  and  services  features  for  each  customer  requirement 

-Develop  specific  objectives  for  satisfying  customer  requirements 

-Develop  performance  targets  for  each  objective 

-Resolve  goals,  objectives  and  product  features  anomalies 

-Develop/refine  quality  matrices 


6.  Identify,  Understand  and  Document  Current  Business  Processes 

-Conduct/validr  j:  business  systems  planning  (BSP)/Information  Systems  Planning  (ISP)  data 
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“List  business  processes 

“List  current  organization  structures 

-Develop  process/organization  matrix 

-Develop  product  feature/process  matrix 

-Evaluate/analyze/prioritize  relative  process  performance 

-Select  functioniil  process  for  FPI  action 

7.  Document  the  Functional  Architecture 

-Document  the  mission  of  the  functional  area 

-Document  the  inission  of  the  subordinate  functional  activity(s) 

-Relate  functional  area  and  activity(s)  to  Enterprise  Architecture 
-Describe  the  business  process(s)  (of  activity)  subject  to  process  improvement 
“Identify  all  organizational  impacts  for  the  business  process(s) 

-Establish  scope  of  effort  for  improving  the  business  process(s) 

“Identify  and  charter  the  Functional  Activity  Program  Manager 
-Restate/revise  the  parameters  for  process  improvement 

-  Process  objectives 

-  Performance  measures  and  methods 
“  Performance  targets 

“  Current  performance  variances  to  targets 
“Develop  the  Functional  Management  Strategy 
-Secure  OSD  Principle  Staff  Assistant  approval  to  proceed 

8.  Initiate  Functional  Process  Improvement  Project 

“Develop  project  plan 

-  Develop  project  scope 

-  Develop  work  breakdown  structure  (WBS) 

-  Develop  organization  breakdown  structure  (OBS) 

-  Select  process  improvement  action  team  (PAT) 

-  Identify  project  resources  and  facilities 

-  Develop  resource  assignment  matrix  (RAM) 

-  Develop  initial  schedules 

-  Develop  initial  cost  estimates 
-Conduct  initial  craining 

-Develop  projeci  execution  management  plan 
-Launch  project 

Process  Analysis  FProblems/OpDortunitiesI  (Steps  9-1  3) 

9.  Review,  Revise  or  Develop  AS-IS  Activity  Models  for  Selected  Process 

-Model  AS-IS  process/activities 
-Model  AS-IS  activity  process  flow 
“Review  process  models 
“Update  process  models 
“Validate  process  models 

10.  Review,  Revise  or  Develop  AS-IS  Data  Models  for  Selected  Process 

“Model  AS-IS  (^ta  models 
-Review  data  models 
-Update  data  models 
-Validate  data  models 
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1 1 .  Perform  Activity-Based  Costing  Study  of  AS-IS  Process 

-Review  metrics,  measures  and  methods 
-Conduct  activity-based  costing 

-  Analyze  activities 

-  Gather  cost  data 

-  Trace  costs  to  activities 

-  Establish  output  measures 

-  Analyze  costs 
-Conduct  time-line  analysis 

12.  Conduct  Cost/Process  Benchmarking  and  Best  Practice  Analysis  with  respect  to  AS-IS  Models 

-Develop  benchmarking  strategy 

-  Identify  features,  functions  and  services 

-  Identify  operating,  administrative  and  personnel  cost  categories 

-Select  and  screen  comparison  companies 
-Collect  data 

-  Proprietary  information 

-  Physical  observation 

-  Trade  data 
-Develop  conclusions 
-Refine  perform?  nee  targets 

13.  Perform  Functional  Process  Improvement  Analysis 

-Review  objectives  and  measures 

-  Produce  the  "right”  products  and  services 

-  Consistency  of  performance 

-  Timeliness  and  customer  response 

-  Appropriate  cost  (competitive) 

-  Safety,  morale,  job  satisfaction 

-  Good  citizenship  (affect  on  other  organizations) 

-  Customer  relationships  (flexibility,  accommodation) 

-Perform  techniques  to  discover  problems  and  improvement  opportunities 

-  Pareto  analysis 

-  Histograms 

-  Cause  and  effect  diagrams 

-  Scatter  diagrams 

-  Statistical  process  control 

-  Process  simulation 

-Identify  quick  fixes 
-Conduct  what-if  analysis 
-Conduct  scenario  analysis 
-Analyze  cost  ii  vers 

-  Economies  of  scale 

-  Learning  curve  effects 

-  Capacity  utilization 

-  Linkages  (value-chain  analysis)  (overhead) 

-  Interrelationships  (other  business  processes) 

-  Integration  (make  us  buy  analysis) 

-  Timing  0ust-in-time  analysis) 

-  Policy  (constraints,  mandates) 

-  Location  (geographical  analysis) 
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-  Institutional  factors  (environmental  considerations) 

-Analyze  quality  drivers 

-  Inputs  (data  and  materials) 

-  People  (process  personnel) 

-  Equipment  (machines,  computers,  systems) 

-  Methods  (procedures,  rules,  regulations,  training) 

-  Materials  (supplies,  tools) 

-  Environment  (including  location) 

-  Outputs  (data,  products  and  services) 

-  Administrative  functions 

-  External  agencies  and  higher  authority 

-  Feedback  (control  systems,  measurements) 

-Prepare  Lnproyement  Opportunity  Analysis  Report 
-Conduct  in-progress  review  (IPR) 

-Make  IPR  changes  to  AS-IS  models  and  improvement  report 
-Publish  AS-IS  report 

Process  Design/Justification  (Steps  14-21') 

14.  Develop  Process  Improvement  Initiative  Packages  (four  classes) 

-Class  i:  Package  quick  fix  improvement  initiatives 

-Class  2:  Package  improvement  initiatives  fliat  have  little  or  no  impact  on  existing 
information  systems 

-Class  ■>.  Pac^ge  improvement  initiatives  that  have  major  impacts  on  existing 
information  systems 

-Class  4  Package  improvement  initiatives  that  will  require  new  information  systems 
(new  technology) 

-Rank  improvement  initiatives  within  class 

15.  Develop  Potential  High-Level  To-Be  Activity  and  Data  Models 

-Develop/revise  the  "vision"  of  the  To-Be  environment 
-Select  To-Be  concept 

-Select  improvement  packages  for  high-level  modeling 
-Perform  high-level  modeling 

-  Activity  models 

-  Data  models 

-  Process  models 

16.  Revise  Improvement  Initiative  Packages  Based  on  To-Be  Models 

-Develop  clear  statement  of  problem/opportunity 

-Revise  improvement  initiative  packages  based  on  high-level  To-Be  models 
-Develop  assumptions  and  constraints 

-Determine  impicmentation  alternatives  for  each  selected  improvement  initiative  package 

17.  Select  Initiative  Package  Based  on  Economic  Analysis  of  Potential  Alternatives 

-Perform  economic  analysis 

-  Collect  cosi/benefit  data  for  each  alternative 

-  Perform  Risk  Adjusted  Discounted  Cash  Flow  (RADCF)  analysis 

-  Perform  sensitivity  analysis 

-  Docuoient  non-quantitative  considerations 
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18.  Develop  Detailed  To-Be  Activity  and  Data  Models  Based  on  Selected  Initiative  Package 

-Develop  detailed  To-Be  models 

-  Activity  models 

-  Data  models 

-  Process  models 
-Perform  simulation 

-Perform  functional  level  integration  analysis 
-Document  information  systems  support  considerations 

19.  Develop  Preliminary  Functional  Economic  Analysis  (FEA)  Decision  Package 

-Summarize  functional  strategic  plan 

-Identify  functional  activity  performance  measures  and  targets 

-Document  activity  improvement  program 

-Document  economic  analysis  of  proposed  improvement  initiatives 

20.  Develop  Data  Management  and  Technical  Management  Plans 

-Develop  functional  activity  information  systems  strategy 
-Analyze  data  systems 

-Document  recommended  changes  and  redirection 

21 .  Develop  Final  Functional  Economic  Analysis  (FEA)  Decision  Package 

-Document  savings,  benefits  and  risks  of  selected  alternatives 
-Develop  project  white  papers 
-Develop  integrated  financial  plan 

-Update  Planning,  Programming  and  Budgeting  System  (PPBS) 

-DejQne  approval  requirements 
-Obtain  policy  approvals 
-Obtain  FEA  approval 

Improvement  Execution  Plan  (Steps  22-25) 

22.  Develop  Project/Action/Transition  Plans 

-Develop  integrated  implementation  plan 
-Develop  new  goals  and  strategies 
-Establish  new  performance  targets 
-Develop  implementation  schedule 
-Determine  implementation  resource  requirements 
-Establish  implementation  team 
-Designate  implementation  steering  committee 
-Design  project  implementation  controls 

23.  Conduct  Executive  Presentations 

-Prepare  executive  briefing 
-Conduct  executive  briefing 

-Review  recommended  changes  to  the  Project/Action/Transition  Plans 
-Revise  Project/Action/Transition  Plans 
-Produce  project  implementation  plan 

24.  Execute  Approved  FEA 

-Develop  design  specifications 
-Develop  prototype/pilot 
-Manage  change 

-Conduct  IPR  for  steering  committee 
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-Produce  project  execution  report 


25.  Evaluate  Results,  Update  Baseline  Data  and  Document  Lessons  Learned 
-Monitor  industry  trends  and  developments 
-Evaluate  results-of  improvement  action 
-Establish  criteria  for  future  improvement  projects 
-Document  lessons  learned 
-Update  baseline  models  (convert  To-Be  to  AS-IS) 
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APPENDIX  B.  AS-IS  PROCESS  MODEL 


This  appendix  contains  the  components  of  the  As-Is  Process  Model 


documentation.  Table  B-1  is  a  list  of  tables  and  figures  as  they  appear  in  the  appendix. 


Number 

Title 

Table  B-2 

As-Is  Process  Model  Decomposition  Diagram 

Figure  B-1 

As-Is  Process  Model  Node  Tree  Diagram  (SSDO): 

3  Levels  -  Provide  Student  Services 

Figure  B-2 

As-Is  Process  Model  Node  Tree  Diagram  (SSDl): 

4  Levels  -  Obtain  Customer  Input 

Figure  B-3 

As-Is  Process  Model  Node  Tree  Diagram  (SSD2): 

4  Levels  -  Make  Changes  to  Student’s  Course  Activity 
Record 

Figure  B-4 

As-Is  Process  Model  Node  Tree  Diagram  (SSD3): 

4  Levels  -  Grade  Student’s  Exams 

Figure  B-5 

As-Is  Process  Model  Node  Tree  Diagram  (SSD4): 

4  Levels  -  Process  Unit  Activity  Reports 

Figure  B-6 

As-Is  Process  Model  Node  Tree  Diagram  (SSD5); 

4  Levels  -  Process  Request  for  Material 

Figure  B-7 

As-Is  Process  Model  Node  Tree  Diagram  (SSD6): 

4  Levels  -  Process  Requests  for  Registrar  Action 

Table  B-1.  List  of  To-Be  Process  Model  Components. 
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Activity  Number 

Activity  Name 

SSDO 

PROVIDE  STUDENT  SERVICES 

SSDl 

OBTAIN  CUSTOMER  INPUT 

SSDl.l 

PROCESS  INCOMING  PHONE  CALLS 

SSDl. 1.1 

PROCESS  CONVERSANT  CALLS 

SSDl. 1.1.1 

PROVIDE  CONVERSANT  INSTRUCTIONS 

SSDl. 1.1.2 

PROCESS  CONVERSANT  INQUIRY 

SSDl.l. 1.2.1 

OBTAIN  TOUCHTONE  SSN 

SSDl.l. 1.2.2 

OBTAIN  TOUCHTONE  COURSE  NUMBER 

SSDl.l. 1.2.3 

PROVIDE  CONVERSANT  COURSE  STATUS 

SSDl. 1.1.3 

EXIT  CONVERSANT  SYSTEM 

SSDl.1.1.4 

TRANSFER  CALL  TO  MCI  STAFF 

SSDl. 1.1.5 

PROVIDE  ADDITIONAL  CONVERSANT 
INSTRUCTIONS 

SSDl. 1.2 

PROCESS  MCI  OPERATOR- ASSISTED  CALLS 

SSDl. 1.2.1 

PROCESS  PHONE  REQUEST  FOR  STATUS/INFO 

SSDl.1.2.1.1 

INPUT  PHONE  CUSTOMER'S  SSN 

SSDl.1.2.1.2 

PROVIDE  PHONE  CUSTOMER  STATUS 

SSDl.  1.2.2 

PROCESS  PHONE  CHANGE  TO  STUDENT’S 
INFORMATION 

SSDl.1.2.2.1 

PROCESS  PHONE  REQUEST  FOR  ENROLLMENT 

SSDl.1.2.2.1.1 

IDENTIFY  PHONE  ENROLLMENT  CUSTOMER 

SSDl. 1.2.2. 1.1.1 

OBTAIN  SSN  OF  PHONE  ENROLLMENT 

CUSTOMER 

SSDl. 1.2.2.;. 1.2 

INPUT  SSN  OF  PHONE  ENROLLMENT  CUSTOMER 

SSDl.1.2.2.1.2 

DETERMINE  DESIRED  COURSE  OF  PHONE 
ENROLLMENT  CUSTOMER 

SSDl.1.2.2.1.2.1 

OBTAIN  DESIRED  COURSE  NUMBER  OF  PHONE 
ENROLLMENT  CUSTOMER 

SSDl.1.2.2.1.2.2 

INPUT  DESIRED  COURSE  NUMBER  OF  PHONE 
ENROLLMENT  CUSTOMER 

SSDl.1.2.2.1.3 

VERIFY  PHONE  ENROLLMENT  CUSTOMER 
INFORMATION 

SSD1.1.2.2.1.3.r 

VALIDATE  PHONE  ENROLLMENT  CUSTOMER 
INFORMATION 

SSD1.1.2.2J.3.2 

INPUT  MISSING  PHONE  ENROLLMENT 

CUSTOMER  INFORMATION 

SSDl.1.2.2.1.3.3 

VALIDATE  PHONE  ENROLLMENT  CUSTOMER 
MEETS  COURSE  PREREQUISITES 

SSDl.1.2.2.1.4 

ENTER  TRANSACTION  CODE  FOR  PHONE 
ENROLLMENT 

SSDl.1.2.2  1.4.1 

INPUT  TC-A  FOR  PHONE  ENROLLMENT 

Table  B-2.  As-Is  Process  Model  Decomposition  Diagram. 
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Activity  Number 

Activity  Name 

SSDl.1.2.2.1.4.2 

UPDATE  ON-LINE  TRANSACTION  ENROLL  FILE 
WITH  PHONE  ENROLLMENT 

SSDl.1.2.2.2 

PROCESS  PHONE  REQUEST  TO  CHANGE 
INFORMATION 

SSDl.1.2.2.2.1 

IDENTIFY  CUSTOMER  REQUESTING  PHONE 
CHANGE 

SSD1.1.2.2.7..1.1 

OBTAIN  SSN  OF  PHONE  CHANGE  CUSTOMER 

SSDl.1.2.2.2.1.2 

INPUT  SSN  OF  PHONE  CHANGE  CUSTOMER 

SSDl.1.2.2.2.2 

DETERMINE  INFORMATION  TO  CHANGE  BY 
PHONE 

SSD1.L2.2.2.2.1 

PROCESS  PHONE  CHANGE  TO  STUDENT'S  NAME 
(NON- ACTIVE  DUTY  USMC) 

SSDl.1.2.2.2.2.1.1 

OBTAIN  CHANGE  TO  STUDENT'S  NAME  BY 

PHONE  (NON- ACTIVE  DUTY  USMC) 

SSDl.1.2.2.2.2.1.2 

INPUT  CHANGE  TO  STUDENT’S  NAME  BY  PHONE 
(NON- ACTIVE  DUTY  USMC) 

SSDl.1.2.2.2.2.2 

PROCESS  PHONE  CHANGE  TO  STUDENT’S 
ADDRESS  (NON-ACTIVE  DUTY  USMC) 

SSDl.1.2.2.2.2.2.1 

OBTAIN  CHANGE  TO  STUDENT'S  ADDRESS  BY 
PHONE  (NON- ACTIVE  DUTY  USMC) 

SSDl. 1.2  2,2.2.2.2 

INPUT  CHANGE  TO  STUDENT’S  ADDRESS  BY 
PHONE  (NON- ACTIVE  DUTY  USMC) 

SSDl.1.2.2.2.2.3 

PROCESS  PHONE  CHANGE  TO  STUDENT’S  RANK 
(NON-ACTIVE  DUTY  USMC) 

SSDl.1.2.,2.2.2.3.1 

OBTAIN  PHONE  CHANGE  TO  STUDENTS  RANK 
(NON-ACTIVE  DUTY  USMC) 

SSDl.1.2.2.2.2.3.2 

INPUT  PHONE  CHANGE  TO  STUDENT’S  RANK 
(NON- ACTIVE  DUTY  USMC) 

SSDl.1.2.2.2.3 

ENTER  TRANSACTION  CODE  FOR  PHONE 

CHANGE 

SSDl.1.2.2.2.3.1 

INPUT  TC-D  FOR  CHANGE  BY  PHONE 

SSDl.1.2.2.2.3.2 

UPDATE  ON-LINE  TRANSACTION  R-6  FILE  WITH 
PHONE  CHANGE 

SSDl.1.2.2.3 

PROCESS  PHONE  REQUEST  FOR  EXTENTTON 

SSDl.1.2.2.3.1 

IDENTIFY  PHONE  EXTENTTON  CUSTOMER 

SSDl.1.2.2.3.1.1 

OBTAIN  SSN  OF  PHONE  EXTENTION  CUSTOMER 

SSDl.1.2.2.3.1.2 

INPUT  SSN  OF  PHONE  EXTENTTON  CUSTOMER 

SSDl.1.2.2.3.2 

DETERMINE  DESIRED  COURSE  OF  PHONE 
EXTENTION  CUSTOMER 

SSDl. 1.2.2. 3.2.1 

OBTAIN  DESIRED  COURSE  NUMBER  OF  PHONE 
EXTENTION  CUSTOMER 

SSDl.1.2.2.3.2.2 

INPUT  DESIRED  COURSE  NUMBER  OF  PHONE 

Table  B-2.  As-Is  Process  Model  Decomposition  Diagram. 
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Activity  Number 

Activity  Name 

EXTENTION  CUSTOMER 

SSDl.1.2.2.3.3 

VERIFY  PHONE  EXTENTION  CUSTOMER 
INFORMATION 

SSDl.1.2.2.3.3.1 

VALIDATE  PHONE  EXTENTION  CUSTOMER 
INFORMATION 

SSD1.L2.2.3.3.2 

INPUT  MISSING  PHONE  EXTENTION  CUSTOMER 
INFORMATION 

SSDl.1.2.2.3.3.3 

VALIDATE  PHONE  EXTENTION  CUSTOMER 

MEETS  COURESE  PREREQUISITES 

SSDl.1.2.2.3.4 

ENTER  TRANSACTION  CODE  FOR  PHONE 
EXTENTION  CUSTOMER 

SSDl.1.2.2.3.4.1 

INPUT  TC-E  FOR  PHONE  EXTENTION 

SSDl.1.2.2.3.4.2 

UPDATE  ON-LINE  TRANSACTION  R-6  FILE  WITH 
PHONE  EXTENTION 

SSD1.L2.2.4 

PROCESS  PHONE  REQUEST  FOR 

DISENROLLMENT 

SSDl.1.2.2.4.1 

IDENTIFY  PHONE  DISENROLLMENT  CUSTOMER 

SSD1.L2.2.4.1.1 

OBTAIN  SSN  OF  PHONE  DISENROLLMENT 
CUSTOMER 

SSD1.1.2.2A1.2 

INPUT  SSN  OF  PHONE  DISENROLLMENT 
CUSTOMER 

SSDl. 1.2.2.42 

DETERMINE  DESIRED  COURSE  OF  PHONE 
DISENROLLMENT  CUSTOMER 

SSD  1.1. 2.2.42.1 

OBTAIN  DESIRED  COURSE  NUMBER  OF  PHONE 
DISENROLLMENT  CUSTOMER 

SSDl. 1.2.2.42.2 

INPUT  DESIRED  COURSE  NUMBER  OF  PHONE 
DISENROLLMENT  CUSTOMER 

SSDl. 1.2.2.43 

VERIFY  PHONE  DISENROLLMENT  CUSTOMER 
INFORMATION 

SSDl. 1.2.2.43.1 

VALIDATE  PHONE  DISENROLLMENT  CUSTOMER 
INFORMATION 

SSDl. 1.2.2.43.2 

INPUT  MISSING  PHONE  DISENROLLMENT 
CUSTOMER  INFORMATION 

SSDl.1.2.2.4.3.3 

VALIDATE  PHONE  DISENROLLMENT  CUSTOMER 
MEETS  COURSE  PREREQUISITES 

SSDl. 1.2.2.44 

ENTER  TRANSACTION  CODE  FOR  PHONE 
DISENROLLMENT 

SSDl. 1.2.2.441 

INPUT  TC-H  FOR  PHONE  DISENROLLMENT 

SSDl. 1.2.244.2 

UPDATE  ON-LINE  TRANSACTION  R-6  FILE  WITH 
PHONE  DISENROLLMENT 

SSDl.1.2.2.5 

PROCESS  PHONE  REQUEST  FOR  RE¬ 
ENROLLMENT 
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Activity  Number 

Activity  Name 

SSDl.1.2.2.5.1 

IDENTIFY  PHONE  RE-ENROLLMENT  CUSTOMER 

SSDl.1.2.2.5.1.1 

OBTAIN  SSN  OF  PHONE  RE-ENROLLMENT 
CUSTOMER 

SSbl.1.2.2.5.1.2 

INPUT  SSN  OF  PHONE  RE-ENROLLMENT 
CUSTOMER 

SSDl.1.2.2.5.2 

DETERMINE  DESIRED  COURSE  OF  PHONE  RE¬ 
ENROLLMENT  CUSTOMER 

SSDl.1.2.2.5.2.1 

OBTAIN  DESIRED  COURSE  NUMBER  OF  PHONE 
RE-ENROLLMENT  CUSTOMER 

SSDl.1.2.2.5.2.2 

INPUT  DESIRED  COURSE  NUMBER  OF  PHONE  RE¬ 
ENROLLMENT  CUSTOMER 

SSDl.1.2.2.5.3 

VERIFY  PHONE  RE-ENROLLMENT  CUSTOMER 
INFORMATION 

SSDl.1.2.2.5.3.1 

VALIDATE  PHONE  RE-ENROLLMENT  CUSTOMER 
INFORMATION 

SSD1.L2.2.5.3.2 

INPUT  MISSING  PHONE  RE-ENROLLMENT 
CUSTOMER  INFORMATION 

SSDl.1.2.2.5.3.3 

VALIDATE  PHONE  RE-ENROLLMENT  CUSTOMER 
MEETS  COURSE  PREREQUISITES 

SSDl.1.2.2.5  4 

ENTER  TRANSACTION  CODE  FOR  PHONE  RE¬ 
ENROLLMENT 

SSDl.1.2.2.5.4.1 

INPUT  TC-R  FOR  PHONE  RE-ENROLLMENT 
CUSTOMER 

SSDl. 1.2.2  5.4.2 

UPDATE  ON-LINE  TRANSACTION  ENROLL  FILE 
WITH  PHONE  RE-ENROLLMENT 

SSDl. 1.2.3 

PROCESS  PHONE  REQUEST  FOR  MATERIAL 

SSDl.1.2.3.1 

DETERMINE  MATERIAL  PHONE  CUSTOMER 
NEEDS 

SSDl.1.2.3.1.1 

VERIFY  PHONE  CUSTOMER'S  INFORMATION 

SSDl.1.2.3.1.2 

VALIDATE  PHONE  CUSTOMER'S  MATERIAL 
REQUEST 

SSDl.1.2.3.2 

PROCESS  STANDARD  REQUESTS  FOR  MATERIAL 
FOR  PHONE  CUSTOMER 

SSDl.1.2.3.2.1 

VALIDATE  PHONE  CUSTOMER'S  REQUEST 

SSDl.1.2.3.2.2 

VERIFY  AVAILABILITY  OF  MATERIAL 

REQUESTED  BY  PHONE 

SSDl.1.2.3.2.3 

ENTER  TRANSACTION  CODE  FOR  MATERIAL 
REQUESTED  BY  PHONE 

SSDl.1.2.3.2.3.1 

ENTER  TC-I  FOR  PHONE  REQUEST  FOR 
DUPLICATE  EXAM 

SSDl. 1.2.5. 2.3.2 

ENTER  TC-P  FOR  PHONE  REQUEST  FOR 
DUPLICATE  COURSE/PROGRAM 
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Activity  Number 

Activity  Name 

SSDLl.2.3.2.3.3 

ENTER  TC-T  FOR  PHONE  REQUEST  FOR 
INDIVIDUAL  GENERIC  DP-37 

SSDl.1.2.3.2.3.4 

ENTER  TC-Y  FOR  PHONE  REQUEST  FOR 
DUPLICATE  DIPLOMA/COMPLETION 

CERTIFICATE 

SSDl.1.2.3.3 

PREPARE  "REQUEST  FOR  MATERIAL"  FORM  FOR 
PHONE  CUSTOMER 

SSDl.1.2.3.3.1 

OBTAIN  BLANK  "REQUEST  FOR  MATERIAL" 

FORM 

SSDl.1.2.3.3.2 

WRITE  PHONE  CUSTOMER’S  NAME  ON 
"REQUEST  FOR  MATERIAL"  FORM 

SSDl.1.2.3.3.3 

WRITE  PHONE  CUSTOMER'S  SSN  ON  "REQUEST 
FOR  MATERIAL"  FORM 

SSDl.1.2.3.3.4 

WRITE  PHONE  CUSTOMER'S  ADDRESS  ON 
"REQUEST  FOR  MATERIAL"  FORM 

SSDl.1.2.3.3.5 

WRITE  PHONE  CUSTOMER'S  DESIRED  ITEM 

NAME  ON  "REQUEST  FOR  MATERIAL"  FORM 

SSDl.1.2.3.3.6 

WRITE  PHONE  CUSTOMER'S  DESIRED  QUANTITY 
ON  "REQUEST  FOR  MATERIAL"  FORM 

SSD1.L2.3.4 

PREPARE  "OFF-LINE  REQUEST"  FORM  FOR 

PHONE  CUSTOMER 

SSDl.1.2.3.4.1 

OBTAIN  BLANK  "OFF-LINE  REQUEST"  FORM 

SSDl.1.2.3.4.2 

WRITE  PHONE  CUSTOMER'S  NAME  ON  "OFF-LINE 
REQUEST"  FORM 

SSDl.1.2.3.4.3 

WRITE  PHONE  CUSTOMER’S  SSN  ON  "OFF-LINE 
REQUEST"  FORM 

SSDl. 1.2.3.44 

WRITE  PHONE  CUSTOMER'S  ADDRESS  ON  "OFF¬ 
LINE  REQUEST"  FORM 

SSDI.1.2.3.4.5 

WRITE  PHONE  CUSTOMER'S  ITEM  NAME  ON 
"OFF-LINE  REQUEST"  FORM 

SSDl.1.2.3.4.6 

WRITE  PHONE  CUSTOMER'S  DESIRED  QUANTITY 
ON  "OFF-LINE  REQUEST"  FORM 

SSD1.2 

SORT  INCOMING  U.S.  MAIL 

SSDl.2.1 

SEGREGATE  STUDENT  COURSE  INPUT 

SSDl.2.1.1 

SEGREGATE  FEEDBACK  FORMS 

SSDl.2.1.2 

SEGREGATE  GENERIC  DP-37s 

SSDl.2.1.3 

SEGREGATE  PRE-SLUGGED  DP-37s 

SSDl.2.1.4 

SEGREGATE  ESSAY  EXAM/LESSONS 

SSDl.2.2 

SEGREGATE  UNIT  INPUT 

SSDl. 2.2.1 

SEGREGATE  UNIT  ACTIVITY  REPORTS 

SSDl. 2.2.2 

SEGREGATE  ENROLLMENTS 

SSDl.2.3 

SEGREGATE  MAILED  CUSTOMER  INQUIRIES 
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Activity  Number 

Activity  Name 

SSDl.2.3.1 

SEGREGATE  WRITTEN  REQUEST  FOR  STATUS 

SSDl.i3.2 

SEGREGATE  WRITTEN  REQUEST  FOR  CHANGE 

TO  CUSTOMER  STATUS 

SSDl. 2.3.3 

SEGREGATE  WRITTEN  CHANGE  TO  CUSTOMER 
INFORMATION 

SSDl. 2.3.4 

SEGREGATE  WRITTEN  REQUEST  FOR  MATERIAL 

SSD1.3 

SORT  INCOMING  E-MAIL 

SSDl.3.1 

PRINT  E-MAIL  MESSAGES 

SSDl.3.2 

SEGREGATE  E-MAIL  REQUEST  FOR  STATUS  / 

INFO 

SSDl.3.3 

SEGREGATE  E-MAIL  REQUEST  FOR  CHANGE  TO 
CUSTOMER  STATUS 

SSDl.3.4 

SEGREGATE  E-MAIL  REQUEST  FOR  MATERIAL 

SSDl.3.5 

SEGREGATE  E-MAIL  UAR  RESPONSE 

SSDl.3.6 

PROCESS  INDIVIDUAL  E-MAIL  RECEIVED 

SSD1.4 

PROCESS  WALK-IN  CUSTOMERS 

SSDl.4.1 

PROCESS  WALK-IN  REQUEST  FOR  STATUS 

SSDl.4.1.1 

INPUT  SSN  OF  WALK-IN  CUSTOMER 

SSDl.4.1.2 

PROVIDE  WALK-IN  CUSTOMER  STATUS 

SSDl.4.2 

PROCESS  WALK-IN  REQUEST  FOR  CHANGE  TO 
CUSTOMER  STATUS  /  INFORMATION 

SSDl.4.3 

PROCESS  WALK-ESf  REQUEST  FOR  MATERIAL 

SSD2 

MAKE  CHANGES  TO  STUDENT’S  COURSE 

ACTIVITY  RECORD 

SSD2.1 

PROCESS  REQUEST  FOR  ENROLLMENT 

SSD2.1.1 

IDENTIFY  ENROLLMENT  CUSTOMER 

SSD2.1.1.1 

OBTAIN  SSN  OF  ENROLLMENT  CUSTOMER 

SSD2.1.1.2 

INPUT  SSN  OF  ENROLLMENT  CUSTOMER 

SSD2.1.2 

DETERMINE  TYPE  OF  ENROLLMENT 

SSD2.1.2.1 

PROCESS  REQUEST  FOR  REGULAR 

ENROLLMENT 

SSD2.1.2.1.1 

VERIFY  INFORMATION  OF  REGULAR 
ENROLLMENT  CUSTOMER 

SSD2.1.2.1.1  1 

VALIDATE  INFORMATION  OF  REGULAR 
ENROLLMENT  CUSTOMER 

SSD2.1.2.1.1.2 

INPUT  MISSING  INFORMATION  OF  REGULAR 
ENROLLMENT  CUSTOMER 

SSD2.1.2.1.1.3 

VALIDATE  REGULAR  ENROLLMENT  CUSTOMER 
MEETS  COURSE  PREREQUISITES 

SSD2.1.2.1.2 

DETERMINE  COURSE  OF  REGULAR 

ENROLLMENT  CUSTOMER 
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Activity  Number 

Activity  Name 

SSD2.1.2.1.2.1 

OBTAIN  COURSE  OF  REGULAR  ENROLLMENT 
CUSTOMER 

SSD2.1.2.1.2.2 

INPUT  COURSE  CODE  OF  REGULAR 

ENROLLMENT  CUSTOMER 

SSD2. 1.2.2 

PROCESS  REQUEST  FOR  BULK  ENROLLMENT 

SSD2.1.2.2.1 

VERIFY  INFORMATION  OF  BULK  ENROLLMENT 
CUSTOMER 

SSD2.1.2.2.1.1 

VALIDATE  INFORMATION  OF  BULK 

ENROLLMENT  CUSTOMER 

SSD2. 1.2.2. 1.2 

INPUT  MISSING  INFORMATION  OF  BULK 
ENROLLMENT  CUSTOMER 

SSD2.1.2.2.1.3 

VALIDATE  BULK  ENROLLMENT  CUSTOMER 
MEETS  COURSE  PREREQUISITES 

SSD2.1.2.2.2 

DETERMINE  COURSE  OF  BULK  ENROLLMENT 
CUSTOMER 

SSD2.1.2.2.2.1 

OBTAIN  COURSE  OF  BULK  ENROLLMENT 
CUSTOMER 

SSD2.1.2.2.2;2 

INPUT  COURSE  OF  BULK  ENROLLMENT 
CUSTOMER 

SSD2. 1.2.3 

PROCESS  REQUEST  FOR  ADMINISTRATIVE 
ENROLLMENT 

SSD2.1.2.3.1 

VERIFY  INFORMATION  OF  ADMINISTRATIVE 
ENROLLMENT  CUSTOMER 

SSD2.1.2.3.1.1 

VALIDATE  INFORMATION  OF  ADMINISTRATIVE 
ENROLLMENT  CUSTOMER 

SSD2.1.2.3.1.2 

INPUT  MISSING  INFORMATION  OF 
ADMINISTRATIVE  ENROLLMENT  CUSTOMER 

SSD2.1.2.3.1.3 

VALIDATE  ADMINISTRATIVE  ENROLLMENT 
CUSTOMER  MEETS  COURSE  PREREQUISITES 

SSD2.1.2.3.2 

DETERMINE  COURSE  OF  ADMINISTRATIVE 
ENROLLMENT  CUSTOMER 

SSD2.1.2.3.2.1 

OBTAIN  COURSE  OF  ADMINISTRATIVE 
ENROLLMENT  CUSTOMER 

SSD2.1.2.3.2.2 

INPUT  COURSE  CODE  OF  ADMINISTRATIVE 
ENROLLMENT  CUSTOMER 

SSD2. 1.2.4 

PROCESS  REQUEST  FOR  RE-ENROLLMENT 

SSD2.1.2.4.1 

VERIFY  INFORMATION  OF  RE-ENROLLMENT 
CUSTOMER 

SSD2.1.2.4.1.1 

VALIDATE  INFORMATION  OF  RE-ENROLLMENT 
CUSTOMER 

SSD2.1.2.4.1.2 

INPUT  MISSING  INFORMATION  OF  RE¬ 
ENROLLMENT  CUSTOMER 

Table  B-2.  As-Is  Prc  oess  Model  Decomposition  Diagram. 

188 


Activity  Number 

Activity  Name 

SSD2.1.2.4.1.3 

VALIDATE  RE-ENROLLMENT  CUSTOMER  MEETS 
COURSE  PREREQUISITES 

SSD2.1. 2.4.2, 

DETERMINE  COURSE  OF  RE-ENROLLMENT 
CUSTOMER 

SSD2.1.2.4.2.1 

OBTAIN  COURSE  OF  RE-ENROLLMENT 

CUSTOMER 

SSD2.1.2.4.2.2 

INPUT  COURSE  OF  RE-ENROLLMENT  CUSTOMER 

SSD2. 1.2.5 

PROCESS  REQUEST  FOR  SPECIAL  RE¬ 
ENROLLMENT 

SSD2.1. 2.5.1 

VERIFY  INFORMATION  OF  SPECIAL  RE¬ 
ENROLLMENT  CUSTOMER 

SSD2. 1.2.5. 1.1 

VALIDATE  INFORMATION  OF  SPECIAL  RE¬ 
ENROLLMENT  CUSTOMER 

SSD2.1.2.5.1.2 

INPUT  MISSING  INFORMATION  OF  SPECIAL  RE¬ 
ENROLLMENT  CUSTOMER 

SSD2.1.2.5.1.3 

VALIDATE  SPECIAL  RE-ENROLLMENT 

CUSTOMER  MEETS  COURSE  PREREQUISITES 

SSD2.1.2.5.2 

DETERMINE  COURSE  OF  SPECIAL  RE¬ 
ENROLLMENT  CUSTOMER 

SSD2.1.2.5.2.1 

OBTAIN  COURSE  OF  SPECIAL  RE-ENROLLMENT 
CUSTOMER 

SSD2.1.2.5.2.2 

INPUT  COURSE  OF  SPECIAL  RE-ENROLLMENT 
CUSTOMER 

SSD2.1.3 

ENTER  TRANSACTION  CODE  FOR  ENROLLMENT 

SSD2. 1.3.1 

INPUT  TC-A  FOR  REGULAR  ENROLLMENT 

SSD2.1.3.2 

INPUT  TC-B  FOR  BULK  ENROLLMENT 

SSD2. 1.3.3 

INPUT  TC-N  FOR  ADMINISTRATIVE 

ENROLLMENT 

SSD2. 1.3.4 

INPUT  TC-R  FOR  RE-ENROLLMENT 

SSD2. 1.3.5 

INPUT  TC-S  FOR  SPECIAL  RE-ENROLLMENT 

SSD2. 1.3.6 

UPDATE  ON-LINE  TRANSACTION  ENROLL  FILE 
WITH  ENROLLMENT 

SSD2.2 

PROCESS  CHANGE  TO  STUDENT  INFORMATION 

SSD2.2.1 

IDENTIFY  STUDENT  REQUESTING  CHANGE  TO 
INFORMATION 

SSD2.2.1.1 

OBTAIN  SSN  OF  STUDENT  REQUESTING  CHANGE 

SSD2.2.1.2 

INPUT  SSN  OF  STUDENT  REQUESTING  CHANGE 

SSD2.2.2 

DETERMINE  INFORMATION  TO  CHANGE 

SSD2.2.2.1 

PROCESS  CHANGE  TO  STUDENT'S  NAME 

SSD2.2.2.1.1  , 

OBTAIN  CHANGE  TO  STUDENT'S  NAME 

SSD2.2.2.1.2 

INPUT  CHANGE  TO  STUDENT'S  NAME 

SSD2.2.2.2 

PROCESS  CHANGE  TO  STUDENT'S  RANK 
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Activity  Number 

Activity  Name 

SSD2.2.2.2.1 

OBTAIN  CHANGE  TO  STUDENT'S  RANK 

SSD2.2.2.2.2 

INPUT  CHANGE  TO  STUDENT'S  RANK 

SSD2.2.2.3 

PROCESS  CHANGE  TO  SERVICE  COMPONENT 

SSD2.2.2.3.1 

OBTAIN  CHANGE  TO  STUDENT'S  SERVICE 
COMPONENT 

SSD2.2.2.3.2 

INPUT  CHANGE  TO  STUDENT'S  SERVICE 
COMPONENT 

SSD2.2.2.4 

PROCESS  CHANGE  TO  SERVICE  STATUS 

SSD2.2.2.4.1 

OBTAIN  CHANGE  TO  STUDENT'S  SERVICE 

STATUS 

SSD2.2.2.4.2 

INPUT  CHANGE  TO  STUDENT'S  SERVICE 

STATUS 

SSD2.2.2.5 

PROCESS  CHANGE  TO  STUDENT'S  ADDRESS 

SSD2.2.2.5.1 

OBTAIN  CHANGE  TO  STUDENT'S  ADDRESS 

SSD2.2.2.5.2 

INPUT  CHANGE  TO  STUDENT'S  ADDRESS 

SSD2.2.3 

ENTER  TRANSACTION  CODE  FOR  CHANGE 

SSD2.2.3.1 

INPUT  TC-D  FOR  CHANGE  TO  STUDENT'S  DATA 

SSD2.2.3.2 

UPDATE  ON-LINE  TRANSACTION  R-6  FILE  WITH 
CHANGE 

SSD2.3 

PROCESS  REQUEST  FOR  ADMINISTRATIVE 
ACTION 

SSD2.3.1 

PROCESS  REQUEST  FOR  EXTENSION 

SSD2.3.1.1 

IDENTIFY  EXTENSION  STUDENT 

SSD2.3.1.1.1 

OBTAIN  SSN  OF  EXTENSION  STUDENT 

SSD2.3.1.1.2 

INPUT  SSN  OF  EXTENSION  STUDENT 

SSD2.3.1.1.3 

OBTAIN  NAME  OF  EXTENSION  STUDENT 

SSD2.3.1.1.4 

INPUT  NAME  OF  EXTENSION  STUDENT 

SSD2.3.1.2 

VERIFY  INFORMATION  OF  EXTENSION  STUDENT 

SSD2.3.1.2.1 

VALIDATE  INFORMATION  OF  EXTENSION 
STUDENT 

SSD2.3. 1.2.2 

INPUT  MISSING  INFORMATION  FOR  EXTENSION 
STUDENT 

SSD2.3. 1.2.3 

VALIDATE  EXTENSION  STUDENT  MEETS 
PREREQUISITES 

SSD2.3.1.3 

DETERMINE  COURSE  OF  EXTENSION  STUDENT 

SSD2.3.1.3.1 

OBTAIN  COURSE  OF  EXTENSION  STUDENT 

SSD2.3.1.3.2 

INPUT  COURSE  CODE  OF  EXTENSION  STUDENT 

SSD2.3.1.4 

ENTER  TRANSACTION  CODE  FOR  EXTENSION 

SSD2.3.1.4.1 

INPUT  TC-E  FOR  EXTENSION 

SSD2.3. 1.4.2 

UPDATE  ON-LINE  TRANSACTION  R-6  FILE  WITH 
EXTENSION 
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Activity  Number 

1  Activity  Name 

SSD2.3.2 

PROCESS  REQUEST  FOR  DISENROLLMENT 

SSD2.3.2.1 

IDENTIFY  DISENROLLMENT  STUDENT 

SSD2.3.2.L1 

OBTAIN  SSN  OF  DISENROLLMENT  STUDENT 

SSD2.3.2.L2 

INPUT  SSN  OF  DISENROLLMENT  STUDENT 

SSD2.3.2.2 

DETERMINE  COURSE  OF  DISENROLLMENT 
STUDENT 

SSD2.3.2.2.1 

OBTAIN  COURSE  OF  DISENROLLMENT  STUDENT 

SSD2.3.2.2.2 

INPUT  COURSE  OF  DISENROLLMENT  STUDENT 

SSD2.3.2.3 

VERIFY  INFORMATION  OF  DISENROLLMENT 
STUDENT 

SSD2.3.2.3.1 

VALIDATE  INFORMATION  ABOUT 
DISENROLLMENT  CUSTOMER 

SSD2.3.2.3.2 

INPUT  MISSING  INFORMATION  ABOUT 
DISENROLLMENT  CUSTOMER 

SSD2.3.2.3.3 

VALIDATE  DISENROLLMENT  CUSTOMER  MEETS 
PREREQUISITES 

SSD2.3.2.4 

ENTER  TRANSACTION  CODE  FOR 
DISENROLLMENT 

SSD2.3.2.4.1 

INPUT  TC-H  FOR  DISENROLLMENT 

SSD2.3.2.4.2 

UPDATE  ON-LINE  TRANSACTION  R-6  FILE  WITH 
DISENROLLMENT 

SSD2.3.3 

PROCESS  EXAM  ISSUE 

SSD2.3.3.1 

IDENTIFY  STUDENT  FOR  EXAM  ISSUE 

SSD2.3.3.1.1 

OBTAIN  SSN  OF  STUDENT  FOR  EXAM  ISSUE 

SSD2.3.3.1.2 

INPUT  SSN  OF  STUDENT  FOR  EXAM  ISSUE 

SSD2.3.3.1.3 

OBTAIN  NAME  OF  STUDENT  FOR  EXAM  ISSUE 

SSD2.3.3.1.4 

INPUT  NAME  OF  STUDENT  FOR  EXAM  ISSUE 

SSD2.3.3.2 

IDENTIFY  COURSE  FOR  EXAM  ISSUE 

SSD2.3.3.2.1 

OBTAIN  COURSE  FOR  EXAM  ISSUE 

SSD2.3.3.2.2 

INPUT  COURSE  CODE  FOR  EXAM  ISSUE 

SSD2.3.3.3 

VERIFY  STUDENT  INFORMATION  FOR  EXAM 

ISSUE 

SSD2.3.3.3.1 

VALIDATE  INFORMATION  OF  STUDENT  FOR 

EXAM  ISSUE 

SSD2.3.3.3.2 

INPUT  MISSING  INFORMATION  OF  STUDENT  FOR 
EXAM  ISSUE 

SSD2.3.3.3.3 

VALIDATE  STUDENT  MEETS  PREREQUISITES 

FOR  EXAM  ISSUE 

SSD2.3.3.4 

ENTER  TRANSACTION  CODE  FOR  EXAM  ISSUE 

SSD2.3.3.4.1 

INPUT  TC-I  FOR  EXAM  ISSUE 

SSD2.3.3.4.2 

UPDATE  ON-LINE  TRANSACTION  R-6  FILE  FOR 
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Activity  Number 

Activity  Name 

EXAM  ISSUE 

SSD2.3.4 

PROCESS  ADMIN  CREDIT  FOR  PME 

SSD2.3.4.1 

IDENTIFY  CUSTOMER  FOR  PME  ADMIN  CREDIT 

SSD2.3.4.1.1 

OBTAIN  SSN  OF  CUSTOMER  FOR  PME  ADMIN 
CREDIT 

SSD2.3.4.1.2 

INPUT  SSN  OF  CUSTOMER  FOR  PME  ADMIN 
CREDIT 

SSD2.3.4.2 

DETERMINE  COURSE  FOR  PME  ADMIN  CREDIT 

SSD2.3.4.2.1 

OBTAIN  COURSE  FOR  PME  ADMIN  CREDIT 

SSD2.3.4.2.2 

INPUT  COURSE  FOR  PME  ADMIN  CREDIT 

SSD2.3.4.3 

VERIFY  CUSTOMER  INFORMATION  FOR  PME 
ADMIN  CREDIT 

SSD2.3.4.3.1 

VALIDATE  INFORMATION  ABOUT  CUSTOMER 

FOR  PME  ADMIN  CREDIT 

SSD2.3.4.3.2 

INPUT  MISSING  INFORMATION  ABOUT 

CUSTOMER  FOR  PME  ADMIN  CREDIT 

SSD2.3.4.3.3 

VALIDATE  CUSTOMER  FOR  PME  ADMIN  CREDIT 
MEETS  PREREQUISITES 

SSD2.3.4.4 

ENTER  TRANSACTION  CODE  FOR  ADMIN  CREDIT 
FOR  PME 

SSD2.3.4.4.1 

INPUT  TC-0  FOR  PME  ADMIN  CREDIT 

SSD2.3.4.4.2 

UPDATE  ON-LINE  TRANSACTION  R-6  FILE  FOR 
PME  ADMIN  CREDIT 

SSD2.4 

PROCESS  STANDARD  REQUEST  FOR  MATERIAL 

SSD2.4.1 

IDENTIFY  STUDENT  REQUESTING  MATERIAL 

SSD2.4.1.1 

OBTAIN  SSN  OF  STUDENT  REQUESTING 
STANDARD  MATERIAL 

SSD2.4.1.2 

INPUT  SSN  OF  STUDENT  REQUESTING 

STANDARD  MATERIAL 

SSD2.4.2 

DETERMINE  STANDARD  MATERIAL  REQUESTED 

SSD2.4.2.1 

DETERMINE  LESSON  FOR  LESSON  ANSWER 

SHEET  ISSUE 

SSD2.4.2.2 

DETERMINE  COURSE  FOR  DUPLICATE  DIPLOMA/ 
COMPLETION  CERTIFICATE  ISSUE 

SSD2.4.2.3 

DETERMINE  COURSE  FOR  DIDIVIDUAL  DP-37 
ISSUE 

SSD2.4.2.4 

DETERMINE  COURSE  OF  DUPLICATE  COURSE 
MATERIAL  ISSUE 

SSD2.4.3 

INPUT  TRANSACTION  CODE  FOR  STANDARD 
MATERIAL  ISSUE 

SSD2.4.3.1 

INPUT  TC-L  FOR  LESSON  ANSWER  SHEET  ISSUE 

SSD2.4.3.2 

INPUT  TC-P  FOR  DUPLICATE  COURSE 
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Activity  Number 

1  Activity  Name 

MATERIALS  ISSUE 

SSD2.4.3.3 

INPUT  TC-T  FOR  INDIVIDUAL  DP-37  ISSUE 

SSD2.4.3.4 

INPUT  TC-Y  FOR  DUPLICATE  DIPLOMA/ 
COMPLETION  CERTinCATE  ISSUE 

SSD2.4.3.5 

UPDATE  ON-LINE  TRANSACTION  R-6  HLE  FOR 
STANDARD  MATERIAL  ISSUE 

SSD3 

GRADE  STUDENTS’  EXAMS 

SSD3.1 

PROCESS  PRE-SLUGGED  DP-37s 

SSD3.1.1 

RUN  PRE-SLUGGED  DP-37s  THROUGH 

SCANTRON 

SSD3.1.L1 

LOAD  PRE-SLUGGED  DP-37s  INTO  SCANTRON 

SSD3.1.1.2 

CREATE  DISK  WITH  SCORES  FOR  GRADED  PRE¬ 
SLUGGED  DP-37S 

SSD3.1.2 

FILE  SCANNED  PRE-SLUGGED  DP-37s 

SSD3.1.3 

FORWARD  UNSCANNED  PRE-SLUGGED  DP-37s 

TO  BE  HAND  GRADED 

SSD3.2 

PROCESS  GENERIC  DP-37S 

SSD3.2.1 

SCREEN  GENERIC  DP-37s 

SSD3.2.2 

RUN  GENERIC  DP-37s  THROUGH  SCANTRON 

SSD3.2.2.1 

LOAD  GENERIC  DP-37s  INTO  SCANTRON 

SSD3.2.2.2 

CREATE  DISK  WITH  SCORES  FOR  GRADED 
GENERIC  DP-37S 

SSD3.2.3 

HLE  SCANNED  GENERIC  DP-37s 

SSD3.2.4 

FORWARD  UNSCANNED  GENERIC  DP-37s  TO  BE 
HAND  GRADED 

SSD3.3 

PROCESS  OPSCAN  ERROR  LISTING  REPORT 

SSD3.4 

PROCESS  HAND  GRADED  EXAMS 

SSD3.4.1 

HANDGRADE  NON-SCANNABLE  DP-37S 

SSD3.4.2 

ENTER  SCORES  FOR  HAND  GRADED  EXAMS 

SSD3.4.3 

ENTER  SCORES  FOR  PME  EXAMS 

SSD4 

PROCESS  UNIT  ACTIVITY  REPORTS 

SSD4.1 

WORK  RETURNED  UARs 

SSD4.1.1 

MAKE  DESIRED  UPDATES  FROM  UAR 

SSD4.1.1.1 

PROCESS  UAR  REQUEST  FOR  ENROLLMENT 

SSD4.1.1.L1 

IDENTIFY  UAR  ENROLLMENT  CUSTOMER 

SSD4.1.1.1.1.1 

OBTAIN  SSN  OF  UAR  ENROLLMENT  CUSTOMER 

SSD4.1.1.1.1.2 

INPUT  SSN  OF  UAR  ENROLLMENT  CUSTOMER 

SSD4.1. 1.1.2 

DETERMINE  DESIRED  COURSE  OF  UAR 
ENROLLMENT  CUSTOMER 

SSD4.1.1. 1.2.1 

OBTAIN  DESIRED  COURSE  NUMBER  OF  UAR 
ENROLLMENT  CUSTOMER 
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Activity  Number 

Activity  Name 

SSD4. 1.1. 1.2.2 

INPUT  DESIRED  COURSE  NUMBER  OF  UAR 
ENROLLMENT  CUSTOMER 

SSD4.1. 1.1.3 

VERIFY  UAR  ENROLLMENT  CUSTOMER 
INFORMATION 

SSD4. 1.1. 1.3.1 

VALIDATE  UAR  ENROLLMENT  CUSTOMER 
INFORMATION 

SSD4.1.1. 1.3.2 

INPUT  MISSING  UAR  ENROLLMENT  CUSTOMER 
INFORMATION 

SSD4.1.1. 1.3.3 

VALIDATE  UAR  ENROLLMENT  CUSTOMER 

MEETS  COURSE  PRE-REQUISITES 

SSD4.1. 1.1.4 

ENTER  TRANSACTION  CODE  FOR  UAR 
ENROLLMENT 

SSD4.1.1. 1.4.1 

INPUT  TC-A  FOR  UAR  ENROLLMENT 

SSD4.1.1. 1.4.2 

UPDATE  ON-LINE  TRANSACTION  ENROLL  FILE 
WITH  UAR  ENROLLMENT 

SSD4. 1.1.2 

PROCESS  UAR  REQUEST  FOR  DATA  CHANGE 

SSD4.1. 1.2.1 

IDENTIFY  UAR  CUSTOMER  FOR  DATA  CHANGE 

SSD4.1.1.2.1:1 

OBTAIN  SSN  OF  UAR  CHANGE  CUSTOMER 

SSD4.1.1.2.1.2 

INPUT  SSN  OF  UAR  CHANGE  CUSTOMER 

SSD4.1. 1.2.2 

DETERMINE  INFORMATION  TO  CHANGE  BY  UAR 

SSD4.1.1.2.2.1 

PROCESS  UAR  CHANGE  TO  STUDENT'S  NAME 

SSD4.1.1.2.2.1.1 

OBTAIN  UAR  CHANGE  TO  STUDENT'S  NAME 

SSD4.1.1.2.2.1.2 

INPUT  CHANGE  TO  STUDENT'S  NAME  BY  UAR 

SSD4.1.1.2.2.2 

PROCESS  UAR  CHANGE  TO  STUDENT'S 

ADDRESS 

SSD4.1.1.2.2.2.1 

OBTAIN  UAR  CHANGE  TO  STUDENT'S  ADDRESS 

SSD4.1.1.2.2.2.2 

INPUT  UAR  CHANGE  TO  STUDENT'S  ADDRESS 

SSD4. 1.1. 2.2.3 

PROCESS  UAR  CHANGE  TO  STUDENT'S  RANK 

SSD4.1.1.2.2.3.1 

OBTAIN  UAR  CHANGE  TO  STUDENT'S  RANK 

SSD4.1.1.2.2.3.2 

INPUT  UAR  CHANGE  TO  STUDENT’S  RANK 

SSD4.1. 1.2.3 

ENTER  TRANSACTION  CODE  FOR  UAR  CHANGE 

SSD4.1.1.2.3.1 

ENTER  TC-D  FOR  DATA  CHANGE  BY  UAR 

SSD4.1.1.2.3.2 

UPDATE  ON-LINE  TRANSACTION  R-6  FILE  WITH 
UAR CHANGE 

SSD4. 1.1.3 

PROCESS  UAR  REQUEST  FOR  EXTENTION 

SSD4.1.1.3.1 

IDENTIFY  UAR  EXTENTION  CUSTOMER 

SSD4.1.1.3.1.1 

OBTAIN  SSN  OF  UAR  EXTENTION  CUSTOMER 

SSD4.1.1.3.1.2 

INPUT  SSN  OF  UAR  EXTENTION  CUSTOMER 

SSD4.1. 1.3.2 

DETERMINE  DESIRED  COURSE  OF  UAR 
EXTENTION  CUSTOMER 

SSD4.1.1.3.2.1 

OBTAIN  DESIRED  COURSE  NUMBER  OF  UAR 

Table  B-2.  As-Is  Process  Model  Decomposition  Diagram. 

194 


Activity  Number 

Activity  Name 

EXTENTTON  CUSTOMER 

SSD4.1.1.3.2.2 

INPUT  DESIRED  COURSE  NUMBER  OF  UAR 
EXTENITON  CUSTOMER 

SSD4.1. 1.3.3 

VERIFY  UAR  EXTENTION  CUSTOMER 
INFORMATION 

SSD4.1.1.3.3.1 

VALIDATE  UAR  EXTENTION  CUSTOMER 
INFORMATION 

SSD4.1.1.3.3.2 

INPUT  MISSING  UAR  EXTENTION  CUSTOMER 
INFORMATION 

SSD4.1.1.3.3.3 

VALIDATE  UAR  EXTENTION  CUSTOMER  MEETS 
COURSE  PRE-REQUISITES 

SSD4.1.1.3.4 

ENTER  TRANSACTION  CODE  FOR  UAR 
EXTENTION  CUSTOMER 

SSD4.1.1.3.4.1 

INPUT  TC-E  FOR  UAR  EXTENTION 

SSD4.1.1.3.4,2 

UPDATE  ON-LINE  TRANSACTION  R-6  FILE  WITH 
UAR  EXTENTION 

SSD4. 1.1.4 

PROCESS  UAR  REQUEST  FOR  DISENROLLMENT 

SSD4.1. 1.4.1 

IDENTIFY  UAR  DISENROLLMENT  CUSTOMER 

SSD4.1.1.4.1.1 

OBTAIN  SSN  OF  UAR  DISENROLLMENT 
CUSTOMER 

SSD4.1.1.4.1.2 

INPUT  SSN  OF  UAR  DISENROLLMENT 

CUSTOMER 

SSD4.1.1.4.2 

DETERMINE  DESIRED  COURSE  OF  UAR 
DISENROLLMENT  CUSTOMER 

SSD4. 1.1. 4.2.1 

OBTAIN  DESIRED  COURSE  NUMBER  OF  UAR 
DISENROLLMENT  CUSTOMER 

SSD4. 1.1. 4.2.2 

INPUT  DESIRED  COURSE  NUMBER  OF  UAR 
DISENTIOLLMENT  CUSTOMER 

SSD4.1.1.4.3 

VERIFY  UAR  DISENROLLMENT  CUSTOMER 
INFORMATION 

SSD4.1.1.4.3.1 

VALIDATE  UAR  DISENROLLMENT  CUSTOMER 
INFORMATION 

SSD4.1.1.4.3.2 

INPUT  MISSING  UAR  DISENROLLMENT 
CUSTOMER  INFORMATION 

SSD4. 1.1. 4.3.3 

VALIDATE  UAR  DISENROLLMENT  CUSTOMER 
MEETS  PREREQUISITES 

SSD4.1.1.4.4 

ENTER  TRANSACTION  CODE  FOR  UAR 
DISENROLLMENT 

SSD4. 1.1. 4.4.1 

INPUT  TC-H  FOR  UAR  DISENROLLMENT 

SSD4.1.1.4.4.2 

UPDATE  ON-LINE  TRANSACTION  R-6  FILE  WITH 
UAR  DISENROLLMENT 

SSD4. 1.1.5 

PROCESS  UAR  REQUEST  FOR  DUPLICATE 
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Activity  Number 


Activity  Name 


MATERIALS 

SSD4.1. 1.5.1 

IDENTIFY  UAR  DUPLICATE  MATERIALS 
CUSTOMER 

SSD4.1.1.5.1.1 

OBTAIN  SSN  OF  UAR  DUPLICATE  MATERIALS 
CUSTOMER 

SSD4.1.1.5.1.2 

INPUT  SSN  OF  UAR  DUPLICATE  MATERIALS 
CUSTOMER 

SSD4.1. 1.5.2 

DETERMINE  DESIRED  MATERIALS  FOR  UAR 
DUPLICATE  MATERIALS  CUSTOMER 

SSD4.1.1.5.2.1 

OBTAIN  DESIRED  MATERIALS  FOR  UAR 
DUPLICATE  MATERIALS  CUSTOMER 

SSD4.1.1.5.2.2 

DETERMINE  AVAILABILITY  OF  DESIRED 
MATERIALS  FOR  UAR  DUPLICATE  MATERIALS 
CUSTOMER 

SSD4.1. 1.5.3 

VERIFY  UAR  DUPLICATE  MATERIALS 

CUSTOMER  INFORMATION 

SSD4.1.1.5.3.1 

VALIDATE  UAR  DUPLICATE  MATERIALS 
CUSTOMER  INFORMATION 

SSD4.1.1.5.3.2 

INPUT  MISSING  UAR  DUPLICATE  MATERIALS 
CUSTOMER  INFORMATION 

SSD4.1.1.5.3.3 

VALIDATE  UAR  DUPLICATE  MATERIALS 
CUSTOMER  MEETS  PRE-REQUISITES 

SSD4.1. 1.5.4 

ENTER  TRANSACTION  CODE  FOR  UAR 

DUPLICATE  MATERIALS  CUSTOMER 

SSD4.1.1.5.4.1 

INPUT  TC-I  FOR  DUPLICATE  EXAM  BY  UAR 
CUSTOMER 

SSD4.1.1.5.4.2 

INPUT  TC-P  FOR  DUPLICATE  COURSE/ 

PROGRAM  BY  UAR  CUSTOMER 

SSD4.1.1.5.4.3 

INPUT  TC-T  FOR  REPLACEMENT  DP-37  BY  UAR 
CUSTOMER 

SSD4.1.1.5.4.4 

INPUT  TC-Y  FOR  DUPLICATE  Dff LOMA/ 
COMPLETION  CERTIFICATE  BY  UAR  CUSTOMER 

SSD4.1.1.5.4.5 

UPDATE  ON-LINE  TRANSACTION  BATCH  FILE 
WITH  UAR  DUPLICATE  MATERIALS  ORDER 

SSD4.1.1.6 

PROCESS  UAR  REQUEST  FOR  RE-ENROLLMENT 

SSD4.1. 1.6.1 

IDENTIFY  UAR  RE-ENROLLMENT  CUSTOMER 

SSD4.1. 1.6.1. 1 

OBTAIN  SSN  OF  UAR  RE-ENROLLMENT 

CUSTOMER 

SSD4.1.1.6.1.2 

INPUT  SSN  OF  UAR  RE-ENROLLMENT 

CUSTOMER 

SSD4.1. 1.6.2 

DETERMINE  DESIRED  COURSE  OF  UAR  RE¬ 
ENROLLMENT  CUSTOMER 
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Activity  Number 

Activity  Name 

SSD4.1.1.6.2.1 

OBTAIN  DESIRED  COURSE  OF  UAR  RE¬ 
ENROLLMENT  CUSTOMER 

SSD4.1.L6.2.2 

INPUT  DESIRED  COURSE  OF  UAR  RE¬ 
ENROLLMENT  CUSTOMER 

SSD4.1. 1.6.3 

VERIFY  UAR  RE-ENROLLMENT  CUSTOMER 
INFORMATION 

SSD4.1.1.6.3.1 

VALIDATE  UAR  RE-ENROLLMENT  CUSTOMER 
INFORMATION 

SSD4.1.1.6.3.2 

INPUT  MISSING  UAR  RE-ENROLLMENT 
CUSTOMER  INFORMATION 

SSD4.1.1.6.3.3 

VALIDATE  UAR  RE-ENROLLMENT  CUSTOMER 
MEETS  PREREQUISITES 

SSD4.1.1.6.4 

ENTER  TRANSACTION  CODE  FOR  UAR  RE¬ 
ENROLLMENT 

SSD4.1.1.6.4.1 

INPUT  TC-R  FOR  UAR  RE-ENROLLMENT 

SSD4. 1.1. 6.4.2 

UPDATE  ON-LINE  TRANSACTION  ENROLL  FILE 
WITH  UAR  RE-ENROLLMENT 

SSD4.1.2 

PREPARE  MATERIAL  REQUEST  FORMS  FROM 

UAR 

SSD4.1.2.1 

PREPARE  "REQUEST  FOR  MATERIAL"  FORMS 
FROM  UAR 

SSD4.1.2.1.1 

WRITE  STUDENT'S  NAME  ON  "REQUEST  FOR 
MATERIAL"  FORMS  FROM  UAR 

SSD4.1.2.1.2 

WRITE  STUDENT'S  SSN  ON  "REQUEST  FOR 
MATERIAL"  FORMS  FROM  UAR 

SSD4.1.2.1.3 

WRITE  STUDENT'S  ADDRESS  ON  "REQUEST  FOR 
MATERIAL"  FORMS  FROM  UAR 

SSD4.1.2.1.4 

WRITE  DATE  ON  "REQUEST  FOR  MATERIAL" 
FORMS  FROM  UAR 

SSD4.1.2.1.5 

WRITE  UAR  CLERK'S  NAME  "REQUEST  FOR 
MATERIAL"  FORMS  FROM  UAR 

SSD4.1.2.1.6 

WRITE  ITEM  NAME  ON  "REQUEST  FOR 
MATERIAL"  FORMS  FROM  UAR 

SSD4.1.2.1.7  ^ 

WRITE  QUANTITY  ON  "REQUEST  FOR 

MATERIAL"  FORMS  FROM  UAR 

SSD4. 1.2.2 

PREPARE  "OFF-LINE  REQUEST"  FORMS  FROM 

UAR 

SSD4.1. 2.2.1 

WRITE  STUDENT'S  NAME  ON  "OFF-LINE 

REQUEST "  FORMS  FROM  UAR 

SSD4.1. 2.2.2 

WRITE  STUDENT'S  SSN  ON  "OFF-LINE  REQUEST" 
FORMS  FROM  UAR 

SSD4.1. 2.2.3 

WRITE  STUDENT'S  ADDRESS  ON  "OFF-LINE 
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Activity  Number 

Activity  Name 

REQUEST"  FORMS  FROM  UAR 

SSD4.1.2.2.4 

WRITE  DATE  ON  "OFF-LINE  REQUEST"  FORMS 
FROM  UAR 

SSD4.1.2.2.5 

WRITE  UAR  CLERK'S  NAME  ON  "OFF-LINE 
REQUEST"  FORMS  FROM  UAR 

SSD4.1.2.2.6 

WRITE  ITEM  NAME  ON  "OFF-LINE  REQUEST" 
FORMS  FROM  UAR 

SSD4.1.2.2.7 

WRITE  QUANTITY  ON  "OFF-LINE  REQUEST" 
FORMS  FROM  UAR 

SSD4.1.3 

FILE  WORKED  UAR 

SSD4.2 

PROCESS  OUTGOING  UARs  BY  U.S.  MAIL 

SSD4.2.1 

OBTAIN  OUTGOING  PRINTED  UARs 

SSD4.2.2 

PACKAGE  OUTGOING  UARs  BY  U.S.  MAIL 

SSD4.2.2.1 

SEPARATE  PRINTED  UARs  FOR  MAILING 

SSD4.2.2.2 

PLACE  UARs  IN  ENVELOPES 

SSD4.2.2.3 

FORWARD  PACKAGED  UARs  TO  LOGISTICS 

SSD5 

PROCESS  REQUEST  FOR  MATERIAL 

SSD5.1 

SEGREGATE  REQUEST  FOR  REGISTRAR 

ACTION 

SSD5.2 

SEGREGATE  STANDARD  REQUESTS  FOR 
MATERIAL 

SSD5.2.1 

VALIDATE  STUDENT'S  REQUEST 

SSD5.2.2 

VERIFY  AVAILABILITY  OF  REQUESTED 

MATERIAL 

SSD5.2.3 

ENTER  TRANSACTION  CODE  FOR  REQUESTED 
MATERIAL 

SSD5.2.3.1 

ENTER  TC-I  FOR  REQUEST  FOR  DUPLICATE 

EXAM 

SSD5.2.3.2 

ENTER  TC-P  FOR  REQUEST  FOR  DUPLICATE 
COURSE /PROGRAM 

SSD5.2.3.3 

ENTER  TC-T  FOR  REQUEST  FOR  INDIVIDUAL 
GENERIC  DP-37 

SSD5.2.3.4 

ENTER  TC-Y  TO  REQUEST  FOR  DUPLICATE 
DIPLOMA/COMPLETION  CERTMCATE 

SSD5.3 

PROCESS  "REQUEST  FOR  MATERIAL"  FORMS 

SSD5.3.1 

VAT  .ID  ATT.  INFORMATION  ON  "REQUEST  FOR 
MATERIAL"  FORM 

SSD5.3.1.1 

VALIDATE  NAME  ON  "REQUEST  FOR  MATERIAL" 
FORM 

SSD5.3.1.2 

VALIDATE  SSN  ON  "REQUEST  FOR  MATERIAL" 
FORM 

SSD5.3.1.3 

VALIDATE  ADDRESS  ON  "REQUEST  FOR 
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Activity  Number 

Activity  Name 

MATERIAL"  FORM 

SSD5.3.1.4 

VALIDATE  QUANTITY  ON  "REQUEST  FOR 
MATERIAL"  FORM 

SSD5.3.2 

PREPARE  MATERIAL  REQUESTED  ON  "REQUEST 
FOR  MATERIAL"  FORM 

SSD5.3.2.1 

TYPE  "REQUEST  FOR  MATERIAL"  MAILING 
LABELS 

SSD5.3.2.2 

OBTAIN  MATERIAL  REQUESTED  ON  "REQUEST 
FOR  MATERIAL"  FORM 

SSD5.3.3 

PREPARE  PACKAGE  OF  "REQUEST  FOR 

MATERIAL"  FORM 

SSD5.3.3.1 

PLACE  "REQUEST  FOR  MATERIAL"  MAILING 
LABELS  ON  ENVELOPE 

SSD5.3.3.2 

INSERT  MATERIAL  REQUESTED  ON  "REQUEST 
FOR  MATERIAL"  FORM  INTO  ENVELOPE 

SSD5.3.3.3 

FORWARD  "REQUEST  FOR  MATERIAL" 

PACKAGE  TO  LOGISTICS  MAILROOM 

SSD5.4 

SEGREGATE  "OFF-LINE  REQUEST"  FORMS 

SSD5.4.1 

COMPLETE  "OFF-LINE  REQUEST"  FORM 

SSD5.4.2 

VALIDATE  INFORMATION  ON  "OFF-LINE 
REQUEST"  FORM 

SSD5.4.3 

FORWARD  "OFF-LINE  REQUEST"  FORM  TO 
LOGISTICS 

SSD5.4.4 

FORWARD  "OFF-LINE  REQUEST"  FORM  TO 
OPERATIONS 

SSD6 

PROCESS  REQUESTS  FOR  REGISTRAR  ACTION 

SSD6.1 

ISSUE  (RE-ISSUE)  DIPLOMA 

SSD6.1.1 

OBTAIN  DIPLOMA  MAILING  LABELS 

SSD6.1.2 

PRINT  DIPLOMAS 

SSD6. 1.2.1 

LOAD  DPLOMA  PRINT  FILE 

SSD6. 1.2.2 

EXECUTE  DIPLOMA  PRINT  PROGRAM 

SSD6.1.3 

PACKAGE  DIPLOMA  FOR  MAILING 

SSD6.1.3.1 

PLACE  DPLOMA  MAILING  LABEL  ON 

ENVELOPE 

SSD6.1.3.2 

INSERT  DIPLOMA  INTO  ENVELOPE 

SSD6. 1.3.3 

FORWARD  PACKAGED  DPLOMA  TO  LOGISTICS 
MAILROOM 

SSD6.2 

PROCESS  TRANSCRIPT  REQUEST 

SSD6.2.1 

OBTAIN  CUSTOMER  TRANSCRIPT  INFORMATION 

SSD6.2.1.1 

VERIFY  TRANSCRIPT  CUSTOMER'S  PERSONAL 
INFORMATION 

SSD6.2.1.1.1 

VERIFY  TRANSCRIPT  CUSTOMER'S  NAME 
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Activity  Number 

1  Activity  Name 

SSD6.2.1.1.2 

VERIFY  TRANSCRIPT  CUSTOMER'S  SSN 

SSD6.2. 1.1.3 

VERIFY  TRANSCRIPT  CUSTOMER'S  ADDRESS 

SSD6.2. 1.1.4 

VERIFY  TRANSCRIPT  CUSTOMER'S  DATES  OF 
SERVICE 

SSD6.2.1.2 

PERFORM  RESEARCH  FOR  STUDENT  COURSE 
INFORMATION 

SSD6.2. 1.2.1 

SEARCH  ON-LINE  DATA  FOR  STUDENT  COURSE 
INFORMATION 

SSD6.2.1.2.1.1 

SEARCH  ACTIVE  FILES  FOR  TRANSCRIPT 
INFORMATION 

SSD6.2.1.2.1.2 

SEARCH  ARCHIVE  HLES  FOR  TRANSCRIPT 
INFORMATION 

SSD6.2. 1.2.2 

SEARCH  MICROnCHE  DATA  FOR  STUDENT 
COURSE  INFORMATION 

SSD6.2. 1.2.3 

REFER  CUSTOMER  TO  HQMC  FOR  COURSES 

PRIOR  TO  JAN  79 

SSD6.2.1.3 

OBTAIN  STUDENT  COURSE  INFORMATION 

SSD6.2.1.3.1 

OBTAIN  STUDY  HOURS 

SSD6.2.1.3.2 

OBTAIN  ENROLLMENT  DATE 

SSD6.2.1.3.3 

OBTAIN  COMPLETION  DATE 

SSD6.2. 1.3.4 

OBTAIN  GRADE  PERCENT 

SSD6.2. 1.3.5 

OBTAIN  COURSE  NUMBER 

SSD6.2.1.3.6 

OBTAIN  COURSE  TITLE 

SSD6.2.2 

PREPARE  TRANSCRIPT 

SSD6.2.2.1 

COMPLETE  TRANSCRIPT  FORM  ON  SCREEN 

SSD6.2.2.2 

PRINT  TRANSCRIPT 

SSD6.2.2.3 

PRINT  TRANSCRIPT  LETTER 

SSD6.2.2.4 

TYPE  TRANSCRIPT  MAILING  LABEL 

SSD6.2.3 

PACKAGE  TRANSCRIPT  FOR  MAILING 

SSD6.2.3.1 

INSERT  TRANSCRIPT  INTO  ENVELOPE 

SSD6.2.3.2 

INSERT  TRANSCRIPT  LETTER  INTO  ENVELOP 

SSD6.2.3.3 

PLACE  TRANSCRIPT  MAILING  LABEL  ON 
TRANSCRIPT  ENVELOPE 

SSD6.2.3.4 

FORWARD  TRANSCRIPT  PACKAGE  TO  LOGISTICS 
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Figure  B-1.  As-Is  Process  Model  Node  Tree  Diagram  (SSDO). 
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appendix  c.  to-be  process  model 


This  appendix  contains  the  components  of  the  To-Be  Process  Model 
documentation.  Table  C-1  is  a  list  of  tables  and  figures  as  they  appear  in  the  appendix. 


Number 

Title 

Table  C-2 

To-Be  Process  Model  Decomposition  Diagram 

Table  C-3 

To-Be  Activity  Dictionary 

Table  C-4 

To-Be  Arrow  Dictionary 

Figure  C-1 

To-Be  Process  Model  Node  Tree  Diagram  (TO) 

All  Levels  -  Student  Service  Support 

Figure  C-2 

To-Be  Process  Model  Context  Diagram  (T-0) 

Figure  C-3  -  C-37 

To-Be  Process  Model  IDEFO  Diagrams 

Figure  C-38 

To-Be  Process  Model  CRUD  Matrix 

Figure  C-39 

To-Be  Process  Model  Qustered  CR  Matrix 

Table  C-1 .  List  of  To-Be  Process  Model  Components. 
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Activity  Number 

Activity  Name 

TO 

STUDENT  SERVICING 

T1 

CUSTOMER  SERVICING 

Tl.l 

OBTAIN  CUSTOMER  INPUT 

Tl.1.1 

PROCESS  INCOMING  PHONE  CALLS 

Tl.1.2 

PROCESS  WALK-IN  CUSTOMERS 

Tl.1.3 

SORT  INCOMING  U.S.  MAIL 

Tl. 1.3.1 

SEGREGATE  STUDENT  COURSE  INPUT 

Tl.1.3.1.1 

SEGREGATE  FEEDBACK  FORMS 

Tl.1.3.1.2 

SEGREGATE  GENERIC  DP-37s 

Tl.1.3.1.3 

SEGREGATE  PRE-SLUGGED  DP-37s 

Tl.1.3.1.4 

SEGREGATE  ESSAY  EXAMS 

Tl. 1.3.2 

SEGREGATE  MAILED  INQUIRIES 

Tl. 1.3.3 

SEGREGATE  UNIT  INPUT 

Tl.1.4 

SORT  INCOMING  E-MAIL 

Tl.1.4.1 

SEGREGATE  E-MAIL  STATUS  REQUEST 

Tl. 1.4.2 

SEGREGATE  E-MAIL  STATUS  CHANGES 

Tl.l. 4.3 

SEGREGATE  E-MAIL  MATERIAL  REQUESTS 

Tl.  1.4.4 

SEGREGATE  E-MAIL  UAR  RESPONSE 

Tl. 1.4.5 

SEGREGATE  PERSONAL  E-MAIL 

T1.2 

PROVIDE  UNIT  ACTIVITY  SERVICES 

Tl.2.1 

PREPARE  UARs 

Tl.2.2 

WORK  RETURNED  UARs 

T2 

STUDENT  ACTIVITY  SERVICING 

T2.1 

PROCESS  ENROLLMENT 

T2.1.1 

DETERMINE  TYPE  OF  ENROLLMENT 

T2.1.2 

VALIDATE  ENROLLMENT  REQUIREMENTS 

T2. 1.2.1 

EVALUATE  SERVICE  COMPONENT 

T2. 1.2.2 

EVALUATE  GRADE 

T2. 1.2.3 

EVALUATE  COURSE/PROGRAM  HISTORY 

T2.2 

PROCESS  STATUS  REQUEST 

T2.2.1 

PROCESS  COURSE  STATUS  REQUEST 

T2.2.1.1 

DETERMINE  ENROLLMENT  STATUS 

T2.2.1.2 

DETERMINE  COURSE  STATUS 

T2.2.1.3 

DETERMINE  EXAMINATION  STATUS 

T2.2.1.4 

DETERMINE  CERTIHCATION  STATOS 

T2.2.2 

PROCESS  TRANSCRIPT  STATUS  REQUEST 

T2.2.2.1 

DETERMINE  PROGRESS  OF  RESEARCH 

T2.2.2.2 

DETERMINE  TRANSCRIPT  SHIP  DATE 

T2.2.3 

PROCESS  MATERIAL  STATUS  REQUEST 

T2.2.3.1 

DETERMINE  COURSE  MATERIAL  STATUS 

Table  C-2.  To-Be  Process  Model  Decomposition  Diagram. 
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Activity  Number 

Activity  Name 

T2.2.3.2 

DETERMINE  COMPONENT  SHIP  STATUS 

T2.2.3.3 

DETERMINE  JOB  AID  SHIP  STATUS 

T2.2.3.4 

DETERMINE  CERTIFICATION  SHIP  STATUS 

T2.2.3.5 

DETERMINE  UNIT  MATERIAL  SHIP  STATUS 

T2.3 

CHANGE  STUDENT  INFORMATION 

T2.3.1 

PROCESS  NAME  CHANGE 

T2.3.2 

PROCESS  SSN  CHANGE 

T2.3.3 

PROCESS  GRADE  CHANGE 

T2.3.4 

PROCESS  SERVICE  COMPONENT  CHANGE 

T2.3.5 

PROCESS  SERVICE  STATUS  CHANGE 

T2.3.6 

PROCESS  ADDRESS  CHANGE 

T2.4 

PROCESS  ADMINISTRATIVE  ACTION 

T2.4.1 

DETERMINE  TYPE  OF  ADMIN  ACTION 

T2.4.2 

VALIDATE  ADMIN  ACTION 

T2.4.2.1 

EVALUATE  ENROLLMENT  STATUS 

T2.4.2.2 

EVALUATE  EXAM  ISSUE  STATUS 

T2.4.2.3 

EVALUATE  COURSE  HISTORY 

T2.4.2.4 

EVALUATE  OTHER  COURSE  CREDIT 

T2.5 

PROCESS  REQUEST  FOR  MATERIAL 

T2.5.1 

DETERMINE  MATERIAL  AVAILABILITY 

T2.5.2 

VALIDATE  MATERIAL  REQUIREMENTS 

T2.5.2.1 

EVALUATE  STUDENT  STATUS 

T2.5.2.2 

EVALUATE  MILITARY/  DOD  STATUS 

T2.5.2.3 

EVALUATE  UNIT  REP  STATUS 

T2.5.2.4 

EVALUATE  FOREIGN  MILITARY  STATUS 

T3 

GRADING 

T3.1 

PROCESS  DP-37S 

T3.L1 

PROCESS  PRE-SLUGGED  DP-37s 

T3.1.1.1 

SCAN  PRE-SLUGGED  DP-37s 

T3.1.1.2 

FILE  SCANNED  PRE-SLUGGED  DP-37s 

T3.1.1.3 

FORWARD  UNSCANNED  PS  DP-37s 

T3.1.2 

PROCESS  GENERIC  DP-37S 

T3. 1.2.1 

SCAN  GENERIC  DP-37s 

T3.1.2.2 

FILE  SCANNED  GENERIC  DP-37s 

T3.1.2.3 

FORWARD  UNSCANNED  GEN  DP-37s 

T3.2 

PROCESS  HAND  GRADED  EXAMS 

T3.2.1 

HAND  GRADE  NON-SCANNABLE  DP-37s 

T3.2.2 

ENTER  HAND  GRADED  EXAMS  SCORES 

T3.2.3 

ENTER  SCORES  FOR  PME  EXAMS 

T3.3 

RUN  GRADING  PROGRAM 

Table  C-2.  To-Be  Process  Model  Decomposition  Diagram. 
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Activity  Number 

Activity  Name 

T3.3.1 

EDIT  DP-37  DATA 

T3.3.1.1 

EDIT  PRE-SLUGGED  DP-37  DATA 

T3.3.1.2 

EDIT  GENERIC  DP-37  DATA 

T3.3.2 

ANALYZE  DP-37  DATA 

T3.3.2.1 

EVALUATE  EXAM 

T3.3.2.2 

COMPARE  STUDENT  RECORD  HISTORY 

T3.4 

PROCESS  OPSCAN  ERRORS 

T3.4.1 

PRODUCE  OPSCAN  ERROR  REPORT 

T3.4.2 

CORRECT  ERRONEOUS  DP-37 

T3.4.3 

FIND  ERRONEOUS  DP-37 

T4 

REGISTRAR  SERVICING 

T4.1 

ISSUE  DIPLOMA 

T4.1.1 

PRINT  DIPLOMAS 

T4.1.2 

PACKAGE  DIPLOMA  FOR  MAILING 

T4.2 

ISSUE  TRANSCRIPT 

T4.2.1 

VERIFY  REQUESTOR  INFORMATION 

T4.2.1.1 

INPUT  REQUESTOR'S  SSN 

T4.2.1.2 

INPUT  REQUESTOR'S  NAME 

T4.2.1.3 

INPUT  REQUESTOR'S  ADDRESS 

T4.2.1.4 

INPUT  REQUESTOR'S  DATES  OF  SERVICE 

T4.2.2 

RESEARCH  TRANSCRIPT  INFORMATION 

T4.2.2.1 

SEARCH  ON-LINE  DATA 

T4.2.2.1.1 

SEARCH  ACTIVE  FILES 

T4.2.2.1.2 

SEARCH  ARCHIVE  FILES 

T4.2.2.2 

SEARCH  MICROFICHE 

T4.2.2.2.1 

INPUT  COURSE  NUMBER 

T4.2.2.2.2 

INPUT  COURSE  TITLE 

T4.2.2.2.3 

INPUT  COMPLETION  DATE 

T4.2.2.2.4 

INPUT  ENROLLMENT  DATE 

T4.2.2.2.5 

INPUT  GRADE  PERCENT 

T4.2.2.2.6 

INPUT  STUDY  HOURS 

T4.2.2.3 

REFER  CUSTOMER  TO  HQMC 

T4.2.3 

PRINT  TRANSCRIPT 

T4.2.4 

PACKAGE  TRANSCRIPT  FOR  MAILING 

Table  C-2.  To-Be  Process  Model  Decomposition  Diagram. 
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Activity  Name 

Activity  Definition 

ANALYZE  DP-37  DATA 

This  activity  represents  the  process  of 
retrieving  the  DP-37  data  and  grading  it  to 
determine  if  the  examination  passed. 

CHANGE  STUDENT  E^ORMATION 

This  activity  represents  the  processes  that 
enable  the  MCI  clerk  to  change  student 
information.  Information  that  can  be 
changed  includes  name,  rank,  SSN,  address, 
service  status  and  service  component. 

COMPARE  STUDENT  RECORD 
HISTORY 

If  the  student  passes  the  exam,  the  student 
course  record  is  updated  on  the  database  to 
reflect  a  completed  course.  If  the  completed 
course  is  a  PME  course,  the  students 
records  are  read  to  see  if  the  student  has 
completed  all  of  the  sub-courses  for  that 
PME.  If  all  of  the  sub-courses  are  complete, 
the  PME  record  is  updated  to  reflect  a 
completed  Program.  The  record  is  moved 
to  the  history  file  and  a  completion 
certificate  and  diploma  will  be  generated. 

CORRECT  ERRONEOUS  DP-37 

This  activity  represents  the  process  of 
correcting  the  file  containing  all  the  errors 
generated  when  editing  and  grading  the  DP- 
37 s.  This  should  be  done  on-screen  with 
direct  access  to  student  and  course 
information. 

CUSTOMER  SERVICING 

This  business  function  represents  the 
processes  required  to  provide  direct  support 
to  customers  by  receiving  the  input, 
distributing  it  for  processing,  and 
responding  to  the  customer,  when 
applicable. 

DETERMINE  CERTIFICATION  SHIP 
STATUS 

This  activity  identifies  the  shipping  status  of 
specified  material  in  response  to  a  request 
for  completion  certificate  shipping  status. 

DETERMINE  CERTMCATION 

STATUS 

Given  the  requestor  is  enrolled  in  a  course 
or  program,  this  activity  determines  if  a 
completion  certificate  has  been  generated 
and  issued  to  the  student.  The  status  of  the 
student's  completion  certification  is 
returned,  i.e.  issue  date  and  mailed  date 
when  capable. 

Table  C-3.  Activity  Dictionary. 
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Activity  Name 

Activity  Definition 

DETERMINE  COMPONENT  SHIP 
STATUS 

This  activity  identifies  the  shipping  status  of 
specified  material  in  response  to  a  request 
for  component  materials  shipping  status. 

DETERMINE  COURSE  MATERIAL 
STATUS 

This  activity  identifies  the  shipping  status  of 
specified  material  in  response  to  a  request 
for  course  or  program  materials  status. 

DETERMINE  COURSE  STATUS 

Given  the  requestor  is  enrolled  in  a  course 
or  program,  this  activity  determines  the 
status  of  the  student's  progress  in  that 
course  or  program,  i.e.  the  number  of 
lessons  completed  (if  required  to  be 
submitted). 

DETERMINE  ENROLLMENT  STATUS 

This  activity  determines  if  the  requestor  is 
enrolled  in  the  course  identified  and 
determines  the  status  of  that  enrollment 

DETERMINE  EXAMINATION  STATUS 

Given  the  requestor  is  enrolled  in  a  course 
or  program,  this  activity  determines  if  the 
exam  has  been  issued,  graded,  or  being 
processed  from  the  Error  Listing.  The 
status  of  the  student's  progress  or  status  on 
the  exam  is  produced. 

DETERMINE  JOB  AID  SHIP  STATUS 

This  activity  identifies  the  shipping  status  of 
specified  material  in  response  to  a  request 
for  job  aid  materials  shipping  status. 

DETERMINE  MATERIAL 
AVAILABILITY 

This  activity  identifies  the  on  hand 
availability  of  material  for  delivery  given  the 
type  of  material  requested. 

DETERMINE  PROGRESS  OF 

RESEARCH 

This  activity  provides  the  status  of  progress 
researching  information  for  a  requestor's 
transcript. 

DETERMINE  TRANSCRIPT  SHIP  DATE 

This  activity  provides  the  shipping  status  of 
a  produced  transcript  in  response  to  a 
transcript  request. 

DETERMINE  TYPE  OF  ADMIN 

ACTION 

This  activity  distinguishes  what  type  of 
administrative  action  is  requested,  i.e. 
disenrollment  or  administrative  credit  for 
PME. 

Table  C-3.  Activity  Dictionary. 
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Activity  Name 

Activity  Definition 

DETERMINE  TYPE  OF  ENROLLMENT 

This  activity  represents  the  process  of 
determining  the  type  of  enrollment  which 
applies  to  the  requestor  for  the  specific 
enrollment.  An  enrollment  can  be  either 
regular  or  administrative.  An  administrative 
enrollment  will  not  issue  materials  but 
registers  the  requestor  into  the  database  as 
a  student. 

DETERMINE  UNIT  MATERIAL  SHff 
STATUS 

This  activity  identifies  the  shipping  status  of 
specified  material  in  response  to  a  request 
for  unit  materials  shipping  status. 

EDIT  DP-37  DATA 

This  activity  represents  the  processes  for 
loading  and  editing  the  DP-37  data. 

EDIT  GENERIC  DP-37  DATA 

This  activity  represents  the  process  of 
editing  the  file  with  data  from  the  generic 
DP-37 s.  It  will  convert  any  numeric  data 
from  answers  to  alpha-numeric  data  and 
ensure  the  required  data  was  scanned 
properly.  It  will  also  draw  student  and 
course  information  from  the  MCIAIS 
database.  This  is  where  proctoring  rules  for 
courses  3520  and  3521  are  enforced.  All 
good  records  build  a  file  to  be  graded.  AU 
failed  records  build  a  file  for  the  Error 
Listing. 

EDIT  PRE-SLUGGED  DP-37  DATA 

This  activity  represents  the  process  of 
editing  the  file  with  data  from  the  pre¬ 
slugged  DP- 37s.  It  will  convert  any  numeric 
data  from  answers  to  alpha-numeric  date 
and  ensure  the  required  data  was  scanned 
properly.  All  good  records  build  a  file  to  be 
graded.  All  failed  records  build  a  file  for  the 
Error  Listing. 

ENTER  HAND  GRADED  EXAMS 
SCORES 

This  activity  represents  the  process  of 
entering  the  scores  from  hand  graded  exams 
into  a  file  for  evaluation. 

ENTER  SCORES  FOR  PME  EXAMS 

This  activity  represents  the  process  of 
entering  the  scores  from  PME  exams  into  a 
file  for  evaluation. 

Table  C-3.  Activity  Dictionary. 
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Activity  Name 

Activity  Definition 

EVALUATE  COUR  SE  HISTORY 

This  activity  evaluates  the  student's  course 
history  to  determine  if  previous  MCI 
products  completed  are  sufficient  to 
provide  the  requested  PME  administrative 
credit.  For  example,  if  the  student  had  been 
enrolled  and  completed  several  courses  in  a 
previous  version  of  the  Command  and  Staff 
Program,  the  student  may  be  eligible  for 
credit  in  part  of  the  current  Command  and 
Staff  Program. 

EVALUATE  COURSE/PROGRAM 
HISTORY 

Process  used  to  determine  if  the  customer 
meets  Course  or  Program  pre-requisites 
based  on  prior  completion  of  other  MCI 
course,  MCI  Programs,  or  Resident 
Programs  attended. 

EVALUATE  ENROLLMENT  STATUS 

This  activity  evaluates  the  enrollment  status 
of  the  student  to  determine  if  student  can  be 
disenrolled  or  to  provide  credit  to  a  course 
the  student  is  enrolled  in. 

EVALUATE  EXAM 

This  activity  determines  the  student's  exam 
score  and  whether  that  score  was  sufficient 
to  pass  the  course. 

EVALUATE  EXAM  ISSUE  STATUS 

This  activity  evaluates  if  the  student's 
record  contains  an  examination  which  has 
been  received  and  graded.  Administrative 
credit  would  not  be  necessary  if  the  student 
had  completed  the  course.  A  course 
completion  would  be  issued  instead  of 
disenrollment  if  the  student  passed  the 
exam. 

EVALUATE  FOREIGN  MILITARY 
STATUS 

This  activity  represents  the  processes 
required  to  validate  the  requestor's 
eligibility  to  be  issued  requested  materials 
based  on  the  status  as  a  member  of  a 
foreign  military  service. 

EVALUATE  GRADn 

Process  used  to  determine  if  the  requestor 
meets  Course  or  Program  pre-requisites 
based  on  grade. 

EVALUATE  MILD  ARY/ DOD  STATUS 

This  activity  represents  the  processes 
required  to  validate  the  requestor's 
eligibility  to  be  issued  requested  materials 
based  on  the  status  as  a  military  or  DoD 
employee. 
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Activity  Name 

Activity  Definition 

EVALUATE  OTHER  COURSE  CREDIT 

This  activity  evaluates  course  work 
completed  from  other  similar  non-MCI 
courses  or  programs  like  might  provide 
similar  areas  of  study  credit,  i.e.  War 

College,  Armed  Forces  Staff  College,  etc. 

EVALUATE  SERVICE  COMPONENT 

Process  used  to  determine  if  the  requestor 
meets  Course  or  Program  pre-requisites 
based  on  service  component. 

EVALUATE  STUDENT  STATUS 

This  activity  represents  the  processes 
required  to  validate  the  requestor's 
eligibility  to  be  issued  requested  materials 
based  on  the  status  as  a  student. 

EVALUATE  UNIT  REP  STATUS 

This  activity  represents  the  processes 
required  to  validate  the  requestor's 
eligibility  to  be  issued  requested  materials 
based  on  the  status  as  a  unit  training 
representative. 

FILE  SCANNED  GENERIC  DP-37s 

This  activity  represents  the  manual  process 
of  filing  the  scanned  DP-37s  into  a  file  after 
successful  scanning  until  the  OpScan  Error 
Listing  is  processed. 

FILE  SCANNED  PRE-SLUGGED  DP-37s 

This  activity  represents  the  manual  process 
of  filing  the  scanned  DP-37  s  into  a  file  after 
successful  scanning  until  the  OpScan  Error 
Listing  is  processed. 

FIND  ERRONEOUS  DP-37 

This  activity  represents  the  process  of 
correcting  the  file  containing  aU  the 
remaining  errors,  after  on-line  processing, 
generated  when  editing  and  grading  the  DP- 
37  s.  This  requires  viewing  the  original  DP- 
37  submitted. 

FORWARD  UNSCANNED  GEN  DP-37s 

This  activity  represents  the  manual  process 
of  forwarding  the  unscannable  DP-37s  to 
the  grading  section  for  hand-grading. 

FORWARD  UNSCANNED  PS  DP-37s 

This  activity  represents  the  manual  process 
of  forwarding  the  unscannable  DP-37s  to 
the  grading  section  for  hand-grading. 

GRADING 

This  business  function  represents  the 
processes  required  to  grade  and  record 
student  examinations  in  the  database. 

Table  C-3.  Activity  Dictionary. 
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Activity  Name 

Activity  Definition 

HAND  GRADE  NON-SCANNABLE  DP- 
37s 

Process  of  hand  grading  DP-37s  either 
rejected  by  the  Scantron  or  received  as 
unscannable  (photo  copy  or  mutilated). 
Involves  locating  course  number  and  exam 
version  number  in  binder  and  extracting  key 
for  hand  grading  exam,  then  manually 
checking  for  passing  score  and  entering 
pass/faQ  information  in  MCIAIS. 

INPUT  COMPLETION  DATE 

Enter  the  requestor’s  Course  completion 
date  from  research. 

INPUT  COURSE  NUMBER 

Enter  the  requestor's  Course  number  from 
research. 

INPUT  COURSE  TITLE 

Enter  the  requestor’s  Course  title  from 
research. 

INPUT  ENROLLMENT  DATE 

Enter  the  requestor's  Course  enrollment 
date  from  research. 

INPUT  GRADE  PERCENT 

Enter  the  requestor's  grade  received  for 
completing  Course  from  research. 

INPUT  REQUESTOR'S  ADDRESS 

Enter  the  requestor's  address. 

INPUT  REQUESTOR’S  DATES  OF 
SERVICE 

Enter  the  requestor's  dates  of  service. 

INPUT  REQUESTOR'S  NAME 

Enter  the  requestor's  name. 

INPUT  REQUESTOR’S  SSN 

Enter  the  requestor's  SSN. 

INPUT  STUDY  HOURS 

Enter  the  requestor's  number  of  study  hours 
for  completing  Course  from  research. 

ISSUE  DIPLOMA 

This  activity  represents  the  processes 
required  to  produce  and  issue  diplomas  to 
student's  completing  the  required  Courses 
for  MCI  Programs.  This  activity  also 
applies  to  requests  for  duplicate  diplomas. 

ISSUE  TRANSCRIPT 

This  activity  represents  the  process  of 
preparing  a  transcript  and  the  form  letter 
reply  in  response  to  a  transcript  request. 

OBTAIN  CUSTOMER  INPUT 

This  activity  represents  the  processes  of 
receiving  input  from  customers  and  the 
subsequent  distribution  of  the  input  for 
processing.  Input  can  be  received  by  phone, 
walk-in,  U.S.  Mail,  or  electronic  mail  (also 
considered  as  naval  message). 

PACKAGE  DIPLOMA  FOR  MAILING 

This  activity  represents  the  process  of 
packaging  the  diploma  into  an  envelope  for 
mailing. 
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Activity  Name  I 

Activity  Definition 

PACKAGE  TRANSCRIPT  FOR 

MAILING 

This  activity  represents  the  processes 
required  to  package  and  deliver  a  student's 
transcript  in  response  to  a  transcript 
request. 

PREPARE  UARs 

This  activity  represents  the  generation  of  a 
Unit  Activity  Report  used  to  reconcile 
student  activity  with  a  Marine  Coip  Unit 
and  the  unit  commander  with  unit  MCI 
participation  sununary  information. 

PRINT  DIPLOMAS 

This  activity  represents  the  process  of 
printing  diplomas  to  be  issued  or  re-issued. 

PRINT  TRANSCRIPT 

This  activity  represents  the  process  of 
preparing  a  transcript  and  the  form  letter 
reply  in  response  to  a  transcript  request. 

PROCESS  GENERIC  DP-37S 

This  activity  represents  the  processes 
required  to  build  input  files  with  data  firom 
the  student  exams  that  have  not  been  pre¬ 
slugged  with  student  and  course 
information  for  evaluation. 

PROCESS  ADDRESS  CHANGE 

This  activity  represents  the  process  of 
changing  a  student's  address. 

PROCESS  ADMINISTRATIVE  ACTION 

This  activity  represents  the  processes  of 
completing  administrative  actions  such  as, 
disenrollment  and  administrative  credit  for 
Professional  Military  Education  Courses. 

PROCESS  COURSE  STATUS  REQUEST 

This  activity  represents  the  processes 
required  to  provide  a  student  the  status  on 
the  courses  and/or  programs  in  which 
currently  enrolled. 

PROCESS  DP-37S 

This  activity  represents  the  processes 
required  to  build  files  with  data  from  the 
student  exams  (DP-37)  for  evaluation. 
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Activity  Name 

Activity  Definition 

PROCESS  ENROLLMENT 

This  activity  refers  to  the  enrollment  of  a 
requestor  into  an  MCI  Course  or  MQ 
Program.  The  processes  require  identifying 
the  requestor,  the  requested 
coturse/program,  and  determining  eligibility 
for  eiuroUment  based  on  course/program 
pre-requisites.  Once  enrolled,  a  requestor  is 
considered  a  Student.  There  are  two  types 
of  enrollments;  Regular  and  Administrative. 
The  enrollment  action  generates  the 
necessary  flags  to  initiate  delivery  of  course 
or  program  materials. 

PROCESS  GRADE  CHANGE 

This  activity  represents  the  process  of 
changing  a  student's  rank. 

PROCESS  HAND  GRADED  EXAMS 

This  activity  represents  the  process  of 
manually  hand  grading  examinations  (DP- 
37s)  which  could  not  be  scanned,  entering 
the  scores  for  those  exams,  and  entering  the 
scores  for  PME  examinations/essays. 

PROCESS  INCOMING  PHONE  CALLS 

This  activity  represents  the  processing  of 
incoming  phone  calls  by  an  MCI  Immediate 
Assist  Clerk.  This  includes  such  activities  as 
processing  an  enrollment,  providing  status 
and  general  information  about  MCI 

Products  (Job  Aids,  Courses  and 

Programs),  changing  student  information, 
administrative  action  (disenrollment  and 

PME  credit),  and  issuing  material  in 
response  to  a  request. 

PROCESS  MATERIAL  STATUS 
REQUEST 

This  activity  identifies  the  shipping  status  of 
specified  material  in  response  to  a  shipping 
status  request  for  component,  job  aid, 
course,  program,  or  unit  material. 

PROCESS  NAME  CHANGE 

This  activity  represents  the  process  of 
changing  a  student's  name. 

PROCESS  OPSCAN  ERRORS 

This  activity  represents  the  processes 
performed  to  generate  the  Opscan  Error 
Report  file  and  correcting  the  errors  on  the 
file,  both  on-screen  and  using  the  original 
DP-37  if  necessary. 
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Activity  Name 

Activity  Definition 

PROCESS  PRE-SLUGGED  DP-37s 

This  activity  represents  the  processes 
required  to  build  files  with  data  from  the 
student  exams  that  have  been  pre-slugged 
with  student  and  course  information  for 
evaluation. 

PROCESS  REQUEST  FOR  MATERIAL 

This  activity  represents  the  processes  for 
filling  customer  requests  for  material  such 
as,  courses,  programs,  components  of 
courses  or  programs,  job  aids  and  Training 
NCO  material. 

PROCESS  SERVICE  COMPONENT 
CHANGE 

This  activity  represents  the  process  of 
changing  a  student's  service  component. 

PROCESS  SERVICE  STATUS  CHANGE 

This  activity  represents  the  process  of 
changing  a  student's  service  status. 

PROCESS  SSN  CHANGE 

This  activity  represents  the  process  of 
changing  a  student's  SSN. 

PROCESS  STATUS  REQUEST 

This  activity  represents  the  processes 
performed  to  provide  student's  with  status 
for  their  requests.  Information  is  provided 
on  a  student's  status  within  a  Course  or 
Program,  status  on  transcript  preparation, 
and  status  on  material  requests. 

PROCESS  TRANSCRIPT  STATUS 
REQUEST 

This  activity  provides  the  status  of  progress 
researching  information  for  a  requestor's 
transcript  and  the  shipping  status  of  a 
produced  transcript  in  response  to  a 
transcript  request. 

PROCESS  WALK-IN  CUSTOMERS 

This  activity  represents  the  processing  of  a 
walk-in  customer  by  an  MCI  Immediate 
Assist  Clerk.  This  includes  such  activities  as 
processing  an  enrollment,  providing  status 
and  general  information  about  MCI 

Products  (Job  Aids,  Courses  and 

Programs),  changing  student  information, 
administrative  action  (disenroUment  and 
PME  credit),  and  issuing  material  in 
response  to  a  request. 

PRODUCE  OPSCAN  ERROR  REPORT 

This  activity  represents  the  activities 
required  to  generate  the  file  containing  all 
the  errors  generated  when  editing  and 
grading  the  DP-37  s. 
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Activity  Name 

Activity  Definition 

PROVIDE  UNIT  ACTIVITY  SERVICES 

This  activity  represents  the  processes  of 
receiving  input  from  Unit  Activity 
customers  (Training  NCOs)  and  the 
subsequent  processes  to  facilitate 
reconciliation  with  the  Unit  as  a  customer. 
Input  can  be  received  by  phone,  walk-in, 

U.S.  Mail,  or  electronic  maU  (also 
considered  as  naval  message). 

Reconciliation  is  initiated  with  a  periodic 

Unit  Activity  Report. 

REFER  CUSTOMER  TO  HQMC 

This  activity  represents  the  referral  of 
transcript  customer  to  HQMC  for  transcript 
information  prior  to  Jan  1979. 

REGISTRAR  SERVICING 

This  business  function  represents  the 
processes  required  to  issue  diplomas  and 
research,  produce  and  deliver  transcripts. 

RESEARCH  TRANSCRIPT 
INFORMATION 

This  activity  represents  the  processes 
performed  to  research  and  input 
information  required  to  produce  a 
transcript. 

RUN  GRADING  PROGRAM 

This  activity  represents  the  process  of 
grading  the  input  files  containing  the 
scanned  data  from  the  student 
examinations. 

SCAN  GENERIC  DP-37s 

This  activity  represents  the  processes  of 
loading  the  OpScanner  with  Generic  DP- 
37s  to  get  the  student's  exam  data  and 
format  that  data  into  a  file  for  the  grading 
program. 

SCAN  PRE-SLUGGED  DP-37s 

This  activity  represents  the  processes  of 
loading  the  OpScanner  with  Pre-Slugged 
DP-37S  to  get  the  student's  exam  data  and 
format  that  data  into  a  file  for  the  grading 
program. 

SEARCH  ACTIVE  FILES 

This  activity  represents  the  process  of 
searching  the  active  records  of  MCIAIS  for 
transcript  customer's  course  completion 
history. 

SEARCH  ARCHIVE  FILES 

This  activity  represents  the  process  of 
searching  the  archived  records  of  MCIAIS 
for  transcript  customer's  course  completion 
history. 
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Activity  Name 

Activity  Definition 

SEARCH  MICROFICHE 

This  activity  searches  archive  records  on 
microfiche  for  transcript  customer's  course 
completion  history. 

SEARCH  ON-LINE  DATA 

This  activity  searches  MCIAIS  active  and 
archive  records  for  transcript  customer's 
course  completion  history. 

SEGREGATE  E-MAIL  MATERIAL 
REQUESTS 

This  activity  represents  the  redistribution  of 
electronic  mail  requesting  material  to  the 
Processing  Section  mail-box  for  material 
requests. 

SEGREGATE  E-MAIL  STATUS 
CHANGES 

This  activity  represents  the  redistribution  of 
electronic  mail  requesting  a  change  to  a 
requestor's  status  to  the  Processing  Section 
mail-box  for  status  change  requests. 
Changing  status  includes  enrolling, 
changing  personal  information,  disenroUing, 
or  completion  of  a  course  or  part  of  a 
program  with  administrative  credit. 

SEGREGATE  E-MAIL  STATUS 
REQUEST 

This  activity  represents  the  redistribution  of 
electronic  mail  requesting  status  to  the 
Processing  Section  mail-box  for  status 
requests. 

SEGREGATE  E-MAIL  UAR  RESPONSE 

This  activity  represents  the  redistribution  of 
electronic  mail  Unit  Activity  Reports  to  the 
Unit  Activity  Report  Section  mail-box. 

SEGREGATE  ESSAY  EXAMS 

This  activity  represents  the  process  of 
separating  PME  essay  exams  and  forwards 
them  to  PMED  for  grading. 

SEGREGATE  FEEDBACK  FORMS 

The  process  removes  PMED  and  OSD  feed 
back  forms  from  the  student  course  input 
received  and  forwards  them  to  PMED  or 
OSD  for  processing. 

SEGREGATE  GENERIC  DP-37s 

This  manual  process  segregates  exams  and 
lessons  which  have  not  been  pre-formatted 
with  user  information  for  the  specific  course 
or  program  (generic  DP-37 s)  and  forwards 
them  to  be  graded. 
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Activity  Name  I  Activity  Definition 

SEGREGATE  MAILED  INQUIRIES  This  process  receives  Mailed  Customer 

Inquiries  and  forwards  the  Input  to 
subsequent  activities  for  processing.  The 
Mailed  Customer  Inquiries  consist  of 
requests  for  enrollment,  requests  for 
missing  course  materials,  missing 
diplomas/completion  certificates,  requests 
for  transcripts,  requests  for  disenroUment, 
requests  for  status  of  student  progress, 
requests  for  course  catalogs,  requests  for 
information  about  courses  in  general, 
change  address  information  on  individual, 
from  either  a  student  or  a  unit 
representative.  The  requests  for  Transcripts 
are  forwarded  to  the  Registrar  Section;  the 
requests  for  Completion  Certificates, 
Diplomas,  replacement  materials, 
enrollment,  disenroUment,  and  changes  to 
information  are  forwarded  to  the  Processing 

_ Section. _ 

SEGREGATE  PERSONAL  E-MAIL  This  activity  represents  the  redistribution  of 

electronic  mail  to  a  specific  individual’s 

_ mail-box  for  processing. _ 

SEGREGATE  PRE-SLUGGED  DP-37s  This  manual  process  segregates  exams  and 

lessons  which  have  been  pre-formatted  with 
user  information  peculiar  to  the  specific 
course  or  program  (Pre-Slugged  DP-37 s) 

_ and  forwards  them  to  be  graded. _ 

SEGREGATE  STUDENT  COURSE  This  activity  processes  Student  Course 

INPUT  Input  and  forwarded  to  subsequent 

activities.  The  Student  Course  Input  should 
include  a  completed  lesson  or  course 
examination  (DP-37),  or  a  copy  of  a 
completed  DP-37,  and  a  feedback  sheet. 

The  feedback  sheet  is  forwarded  to  either 
PMED  or  OSD  according  to  the 
course/lesson  completed.  The  DP-37s  are 
segregated  by  tjq^e  (Generic  or  Pre- 
Slugged)  and  forwarded  to  the  grading 
section. 
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Activity  Name 

Activity  Definition 

SEGREGATE  UNIT  INPUT 

This  activity  represents  the  process  of 
receiving  Unit  Input  and  forwarding  the 
Input  to  the  UAR  section  for  processing. 

The  Unit  Input  should  include  a  Unit 

Activity  Report  (UAR)  or  request  for  Unit 
support  material.  UAR  input  includes 
requests  for,  and  submission  of,  information 
on  behalf  of  a  Student. 

SORT  INCOMING  E-MAIL 

This  activity  represents  the  processes 
performed  with  incoming  electronic  mail. 
This  includes  distribution  for  processing 
within  SSD  and  forwarding  correspondence 
to  other  personnel,  divisions,  and 
departments  within  MCI. 

SORT  INCOMING  U.S.  MAIL 

This  activity  represents  the  processes 
performed  with  incoming  mad.  This 
includes  segregation  and  distribution  for 
processing  within  SSD  and  forwarding 
correspondence  to  other  departments  within 
MQ. 

STUDENT  ACTIVITY  SERVICING 

This  business  function  represents  the 
processes  required  to  maintain  a  student's 
course  activity  record  in  the  database.  It 
includes  the  enrollmeni,  maintenance 
activities,  providing  status,  and  issuing 
material. 

STUDENT  SERVICING 

This  functional  area  represents  the  business 
processes  required  to  run  a  successful 
Student  Services  Department.  It  includes 
the  entire  cycle  of  servicing  a  student  from 
enrollment  in  a  Course  or  Program  until 
completion  certification.  It  also  includes  the 
processes  to  service  customers  obtaining 
other  MCI  Products  such  as  Job  Aids, 
Course/Program  components  and  materials, 
and  Unit  MCI  Materials  without  enrolling  in 
a  Course  or  Program. 

VALIDATE  ADMIN  ACTION 

This  activity  represents  the  process  of 
ensuring  the  student  meets  the  requirements 
necessary  to  effect  the  requested 
administrative  action  for  the  specified 

Course  or  Program. 
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Activity  Name 

Activity  Definition 

VALIDATE  ENROLLMENT 
REQUIREMENTS 

This  activity  represents  the  processes 
validating  the  requestor's  eligibility  with  the 
pre-requisites  of  the  Course  or  Program  the 
requestor  intends  to  enroll. 

VALIDATE  MATERIAL 
REQUIREMENTS 

This  activity  represents  the  processes 
required  to  validate  the  requestor's 
eligibility  to  be  issued  requested  materials. 

VERIFY  REQUESTOR  INFORMATION 

This  activity  verifies  there  is  sufficient 
information  available  on  student's  request  to 
begin  research  of  transcript  information. 
Information  verified  includes;  Name,  SSN, 
Address,  and  Dates  of  Service, 

WORK  RETURNED  UARs 

This  activity  represents  the  processes  of 
reconciling  student  activity  records  based 
on  input  from  unit  Training  NCOs  and 
updating  MCI  records  with  the  consolidated 
input. 
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Arrow  Name 

Arrow  Definition 

Activity  Transactions/T2 

This  action  calls  the  process  for  Customer  Activity 
Transactions. 

Admin  Action/T2.4 

Calls  activity  to  process  requests  for  administrative  action. 

Admin  Credit  Transaction 

Transaction  occurrence  triggers  an  update  to  the  Student's 
record  giving  administrative  credit  for  Course  on  system 
date. 

Admin  Req  Info 

Transient  information  collected  from  student  and  input  by 
clerk. 

Admin  Requests 

This  is  the  requester's  information  that  requests  the 
administrative  credit  and  is  entered  in  at  the  PC. 

Approved 

Requester  meets  requirements  for  intended  administrative 
action. 

Archived  Student  and  Course 

Student  Master  File  containing  history  of  aU  students 

Data 

enrolled  in  MCI  courses  during  the  period  Jan  1979  -  Jan 
1989.  History  includes:  Course  Number;  SSN;  Last 

Name;  Initials;  Rank;  MOS;  RUC;  Enrollment  date;  Re¬ 
enrollment  date;  Completion  date;  Extension  (Y/N);  Last 
Transaction  code/date;  Exams  -  Date/form/score  for 
primary  and  alternate  if  applicable;  Parent  Group 
Type/Number. 

Automated  Equipment 

All  mechanical  equipment  maintained  in  SSD  to  provide 
support  to  SSD  Operations:  PC,  Microfiche  reader, 
Scantron,  printer,  PBX  Telephone,  etc. 

AVRS 

This  represents  the  Conversant  Automated  Voice 

Response  System  (AVRS)  which  interacts  with  the 
database  to  provide  a  student's  course  status. 

Banyan  E-Mail 

Mechanism  that  enables  personnel  to  receive  and  send 
electronic  correspondence. 

Change  Info/T2.3 

Calls  activity  to  process  changes  to  a  student's  personal 
information. 

Corrected  DP-37s 

DP-37  s  that  had  information  that  failed  to  scan  properly 
or  that  contained  data  that  did  not  pass  the  editing  and 
were  corrected. 

Course  Completion  Data 

This  is  the  information  necessary  to  register  course 
completion  in  the  database  and  initiate  generation  of 
course  completion  certificates. 

Course  Program 

Requirements 

Course  or  Program  requirements  that  determine  the 
requester's  eligibility  to  enroU/disenroll/admin  credit  into 
the  course  or  program. 

Course/Program  Status 
Request 

Inquiry  from  a  requester  for  status  on  a  coiuse  or 
program. 
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Arrow  Name 


Customer  Input 


Customer  Requests 


Diploma  and  Letter 


Diploma  Package 


Diploma  Print  Date 


Disapproved 


DisenroUment  Transaction 


Documentation 


DP-37S 


Eligible 


Enroll/T2.1 


Enrollment  Info 


Enrollment  Request 


Enrollment  Transaction 


Erroneous  DP-37s 


Error  Codes 


Error  Listing  File 


Exam  Answer  Key 


Exam  Evaluation 


Arrow  Definition  _ 


Customer  contact  with  MCI  in  any  media  form:  Phone,  e- 
mail  (includes  DMS  and  DISN),  written  correspondence 
by  U.S.  Mail  (or  similar),  or  by  walk-in.  Customer  input 
can  be  by  the  customer  or  by  the  unit  representative 
calling  on  behalf  of  the  student  or  by  returning  Unit 
Activity  Reports. 


General  bundle  category  of  inquiries  or  other  requests 
from  a  customer:  status,  information,  transcript  request, 
request  for  material,  etc.  _ 


Physical  representation  of  a  Diploma  and  a  form  letter  of 
congratulation  issued  after  completing  aU  the  courses  in  a 
program.  _ 


Package  consisting  of  a  diploma  and  a  form  letter  in  an 
envelope  addressed  for  distribution. 


Updates  MCIAIS  with  date  diploma  is  (re-)printed. 


Requestor  fails  to  meet  requirements  for  intended 
administrative  action.  _ 


Transaction  occurrence  triggers  an  update  disenrollment 
date  of  Students  record. 


Bundled  arrow  representing  the  myriad  of  documentation 
that  is  distributed  to  the  customer. 


A  bubble  sheet  exam  form  that  contains  student  and 
course  information  as  well  as  the  student's  answers  to  the 
examination.  _ 


Requestor  passes  restriction  for  receiving  requested 
materials.  _ 


Calls  activity  to  process  enrollment 


Transient  data  representing  the  information  required  to 
enroll  a  student. 


This  is  information  provided  by  the  requester  that  will  be 
keyed  in  to  initiate  an  enrollment  transaction. 


This  represents  a  validated  enrollment  creating  the  flags 
necessary  to  generate  shipping  documentation  when 
called. 


DP-37  information  on  the  error  listin 


Represents  the  information  in  the  error  code  table. 


File,  created  from  DP-37  data  that  do  not  pass  editing,  is 
the  basis  of  OpScan  error  report. 


This  arrow  represents  the  information  contained  in  an 
answer  key. 


Evaluation  of  hand-graded  exam  provides  a  score  for  the 
exam  to  be  entered  into  the  system. 
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Arrow  Name 

Arrow  Definition 

Failed  Exam  Data 

The  data  that  represents  a  student's  failing  score  for  a 
hand-graded  exam,  a  PME  exam,  or  an  exam  score  that 
was  obtained  from  the  grading  program  with  applicable 
information. 

Gen  DP-37  File 

Data  obtained  from  Student's  exam  (Gen  DP-37) 
formatted  into  a  file  for  editing  and  input  into  the  Grading 
Program. 

Gen  TOBESCAN  File 

File,  created  from  formatted  data  obtained  from  Student's 
exam  (Gen  DP-37)  that  passed  editing,  is  the  basis  of  the 
student's  exam  input  file  for  the  Grading  Program. 

Generic  DP-37s 

This  is  the  exam  form  (DP-37)  that  has  not  been  pre¬ 
formatted  with  any  student,  course  and  exam 
identification  information  but  completed  with  the  student's 
answers  to  the  exam. 

Goodscan  File 

Bundled  Arrow:  a  File,  created  from  formatted  data 
obtained  from  Student's  exam  (Gen  DP-37  and  Pre- 
Slugged)  that  passed  editing,  is  the  student's  exam  input 
file  for  the  Grading  Program. 

Grading  Data 

MCIAIS  data  used  to  evaluate  the  student's  exam  in  the 
Grading  Program. 

Hand-Graded  DP-37s 

DP-37s  that  were  rejected  by  the  OpScanner  but  hand 
graded  and  scores  entered  into  MCIAIS. 

Ineligible 

Requester  does  not  pass  restriction  for  receiving 
requested  materials. 

Info  Change  Requests 

This  is  any  request  to  change  personal  information  on  a 
student  Could  be  name,  rank,  SSN,  address,  component, 
etc. 

Information  Changes 

This  is  any  request  to  change  information  on  a  student. 
Could  be  an  enrollment,  disenrollment,  or  other  admin 
action  to  change  personal  information  or  PME  credit 

Invalid  Enrollment 

Enrollment  request  did  not  satisfy  the  requirement  for 
enrollment 

Invoice  Data 

Data  necessary  to  build  an  invoice  for  mailing  course  or 
program  components,  courses  or  program  materials.  Job 
Aids  or  Training  NCO  materials. 

Laser  Jet  Printer 

Laser  Jet  printer  used  for  printing  Diplomas  and 
Transcripts. 

Manual  Exam  Scores 

Source  data  that  is  input  form  hand  grading  exams. 

Marine  Manual  Resources 

Mechanism:  Indicates  where  labor  and  manual  processes 
occur. 
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Arrow  Definition 

Material  Data 

Data  necessary  to  distinguish  material  that  is  issued  as  an 
MCI  product.  Job  Aids,  Exams,  Course/Program 
components,  and  Unit  Training  NCO  Material. 

Material  Info 

Transient  data  that  represents  the  MCI  product  material 
requested:  Job  Aids,  Exams,  Course/Program 
components,  and  Unit  Training  NCO  Material. 

Material  Requests 

Customer  requests  for  material.  Could  be  components  of 
a  course,  program  or  job  aid;  complete  (re-issue)  job  aid, 
course  or  program;  or  re-issue  of  completion  certificate  or 
diploma. 

Material  Shipment  Data 

Data  concerning  material  shipments. 

Material  Status  Request 

Customer's  request  for  status  on  material  shipment. 

MCI  Information 

Information  about  the  course,  programs  and  Job  aids 
distributed  by  MCI.  This  covers  the  Course  Catalog  and 
MCI  Procedures  Manual  (eventually). 

MCI  Procedures  Manual 

MCI's  Procedures  Manual  which  provides  guidance,  to 
student's  and  Training  NCOs  on  the  mission,  functions, 
processes  and  protocols  of  conducting  business  with 

MCI. 

MCI  SOP 

Procedures  documented  by  each  division  to  document 
standard  operating  procedures. 

MCIAIS 

The  entire  MCI  database. 

Microfiche  Reader 

Microfiche  reader  used  to  research  Student  and  Course 
Information  archived  for  period  Jan  1979  -  Jan  1989. 

New  Address 

Updated  information,  from  customer  or  source,  used  to 
make  student  data  current. 

New  Component 

Updated  information,  from  customer  or  source,  used  to 
make  student  data  current. 

New  Name 

Updated  information,  from  customer  or  somce,  used  to 
make  student  data  current. 

New  Rank 

Updated  information,  from  customer  or  source,  used  to 
make  student  data  current. 

New  Service  Status 

Updated  information,  from  customer  or  source,  used  to 
make  student  data  current. 

OPSCAN  Error  List 

Formatted  data  consisting  of  data  from:  failed  exams, 
exams  that  did  not  pass  editing,  control  numbers  for 
identification,  and  error  codes  or  descriptors  to  indicate 
reason  for  failiure. 

OpScanner 

OPSCAN  7  optical  mark  reader. 

OSD/PMED  Feedback 

Evaluations  of  courses  and  programs  often  returned  with 
exam  sheets  following  a  student's  completion  of  an 
examination. 

Table  C-4.  Arrow  Dictionary. 


230 


Arrow  Name 
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Passing  Exam  Data 

The  data  that  represents  a  student's  passing  score  for  a 
hand-graded  exam,  a  PME  exam,  or  an  exam  score  that 
was  obtained  from  the  grading  program  with  applicable 
information. 

PBX  Phone  System 

AT&T  Merlin  telephone/voice-mail  system  used  to 
answer  phone  calls  to  the  1-800-MCI-USMC  telephone 
number. 

PC 

Personal  Computer  to  input  data  and  read  information. 

Personal  E-Mail 

Electronic  mail  intended  to  be  addressed  to  an  individual 
employee  or  division  of  MCI. 

PME  Essay  Evaluation 

Evaluation  of  hand-graded  PME  essay  exam. 

PME  Essays 

Postal  Delivery 

Mechanism:  represents  the  method  of  delivery  of  input  to 
SSD. 

Pre-Slugged  DP-37s 

This  is  the  exam  form  (DP-37)  that  has  been  pre¬ 
formatted  with  student,  course  and  exam  identification 
information  and  completed  with  the  student's  answers  to 
the  exam. 

Process  Hand  Graded 
Exams/T3.2 

Call:  Calls  activity  to  process  hand  grade  exams. 

Process  Material 

Request/T2.5 

Call:  calls  activity  to  process  requests  for  material. 

Process  Status  Request/T2.2 

Call:  Calls  activity  to  process  status  requests. 

Program  Completion  Data 

This  is  the  information  necessary  to  register  program 
completion  in  the  database  and  initiate  generation  of 
course  completion  certificates. 

PS  DP-37  File 

Data  obtained  from  Student's  (Pre-Slugged  DP-37)  exam 
formatted  into  a  file  for  input  into  the  Grading  Program. 

PS  TOBESCANFile 

File,  created  from  formatted  data  obtained  from  Student's 
exam  (Pre-Slugged  DP-37)  that  passed  editing,  is  the 
basis  of  the  student's  exam  input  file  for  the  Grading 
Program. 

Registrar  Data 

MCIAIS  data  required  to  execute  registrar  processes: 
create,  research  and  issue  transcripts,  create  and  issue 
diplomas,  and  accompanied  form  letter. 

Rejected  DP-37s 

This  represents  the  Pre-Slugged  and  Generic  DP- 37s  that 
were  not  successfully  scanned. 

Rejected  Gen  DP-37s 

This  represents  the  Generic  DP-37s  that  were  not 
successfully  scanned. 

Rejected  PS  DP-37s 

This  represents  the  Pre-Slugged  DP- 37s  that  were  not 
successfully  scanned. 
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Reply  to  Customer 

A  reply  to  the  customer  is  in  response  to  a  request  and 
usually  will  be  replied  to  in  the  same  media  the  request 
was  submitted;  enrollment  not  accepted,  course  status, 
rejected  admin  action  request,  not  qualified  to  receive 
requested  materials.  There  are  instances  when  the  reply 
may  be  implied,  i.e.  issuing  a  diploma  in  response  to  an 
exam  or  issuing  material  following  emollment  are 
categories  not  represented  by  this  arrow. 

Returned  UARs 

Unit  Activity  Reports  returned  by  a  supported  unit  that 
has  been  reviewed  and  annotated  with  Training  NCO 
feedback  on  student  status  and  information. 

Scannable  Gen  DP- 37s 

This  represents  the  DP- 37s  that  can  be  scanned  based  on 
physical  condition. 

Scannable  PS  DP-37s 

This  represents  the  DP-37s  that  can  be  scanned  based  on 
physical  condition. 

Scanned  DP-37s 

This  represents  the  Pre-Slugged  and  Generic  DP-37s  that 
were  successfully  scanned. 

Scanned  Gen  DP-37s 

This  represents  the  Generic  DP-37s  that  were  successfully 
scanned. 

Scanned  PS  DP-37s 

This  represents  the  Pre-Slugged  DP-37s  that  were 
successfully  scanned. 

SSN  Change 

Updated  information,  from  customer  or  source,  used  to 
make  student  data  current. 

Status  Data 

MCIAIS  data  required  to  provide  status. 

Status  Request 

The  customer's  request  for  status.  Status  can  be  provided 
on  a  student's  course,  program,  material  shipment, 
transcript. 

Status  Request  on  Comp 
Transcript 

The  customer's  request  for  status  on  a  transcript. 

Student  &  Customer  Info 

Information  resident  on  database  about  students  and 
customers.  This  includes  name,  rank,  SSN,  and  address. 

Student  &  Unit  Data 

Course  and  Program  information  regarding  a  student's 
status  compiled  by  Marine  Unit  (RUC). 

Student  and  Address  Data 

This  arrow  provides  the  activity  with  student  and  address 
data  necessary  to  mail  the  diploma  to  the  student 
completing  the  program. 

Student  and  Course  Data 

The  existing  Student  and  Course  Data  on  the  database. 

Student  Data 

Information  resident  on  database  about  students.  This 
includes  name,  grade,  service  component,  and  SSN. 

Student's  Course  and 

Program  Data 

The  existing  Student,  Course  and  Program  Data  on  a 
specific  instance. 

Student's  Program  Data 

Program  information  for  student's  in  the  database. 
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Arrow  Definition 

Student,  Course  &  Exam 

Data 

The  existing  MCIAIS  Student,  Course  and  Exam  Data. 

Transcript  and  Letter 

This  is  the  transcript  and  the  accompanying  form  letter 
produce  in  response  to  a  transcript  request. 

Transcript  Course  History 

Course  completion  history  of  student  with  accreditation 
data. 

Transcript  Package 

This  is  the  transcript  and  the  accompanying  form  letter 
produced  in  response  to  a  transcript  request  and  packaged 
for  mailing. 

Transcript  Print  Date 

System  date  provided  when  transcript  is  completed  to 
update  MCIAIS  for  future  status  requests. 

Transcript  Request 

Customer's  request  for  a  transcript  or  SSD  clerk's  input 
for  same. 

Transcript  Request 
Information 

This  is  the  Transcript  Customer's  information  required  to 
research  and  produce  a  transcript:  Name,  SSN,  Address, 
Dates  of  Service. 

Transcript  Status  Request 

Customer's  request  for  status  in  response  to  a  transcript 
request  or  S  SD  clerk's  input  for  same. 

UAR 

Unit  Activity  Report  sent  to  Marine  units  for  student 
record  reconciliation. 

UAR  Request 

Customer's  request  for  a  Unit  Activity  Report  or  SSD 
clerk's  input  for  same.  Request  can  be  for  a  single  UAR  or 
group  of  UARs. 

Uncorrectable  DP-37s 

DP-37s  that  could  not  be  corrected  due  to  lack  of 
available  information  provided  on  the  bubble  sheet 
submitted. 

Unscannable  Gen  DP -31$ 

This  represents  the  DP-37s  that  can  not  be  scanned  based 
on  physical  condition  or  OpScanner  rejection. 

Unscannable  PS  DP- 37s 

This  represents  the  DP-37s  that  can  not  be  scanned  based 
on  physical  condition  or  OpScanner  rejection. 

Updated  Student  Info 

Student  information  updated  by  phone  call,  waUc-in,  e- 
mail,  UAR,  or  U.S.  mail.  This  can  be  the  result  of  any  of 
the  student  activity  transactions  include  an  enrollment, 
disenrollment,  student's  information  that  is  changed  like 
name,  rank,  service,  component,  status,  etc.,  or  course 
completion,  but  is  directed  at  updating  personal 
information  which  should  be  verified  prior  to  executing 
the  transaction. 

Valid  Enrollment 

Transient  Enrollment  data  that  passed  evaluation  against 
course/program  requirements. 
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Arrow  Definition 

Work  Returned  UARs/Tl.2.2 

Call:  Calls  activity  to  process  student  activity  servicing  to 
update  student  records  based  on  input  provided  with 
returned  UAR. 

Worked  UAR 

A  Unit  Activity  Report  that  has  been  reconciled  by  the 
using  unit  and  UAR  processing  clerk  has  updated  the 
student  records  based  on  the  reconciliation.  To  File. 
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Figure  C- 1 .  To  Be  Process  Model  Node  Tree  Diagram  (TO). 
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Figure  C-1 8.  To-Be  Process  Model  IDEFO  Diagram  (T2.4). 
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Figure  C-19.  To-Be  Process  Model  DDEFO  Diagram  (T2.4.2) 
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Figure  C-20.  To-Be  Process  Model  BDEFO  Diagram  (T2.5). 
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Figure  C-25 .  To-Be  Process  Model  IDEFO  Diagram  (T3 .1.2). 

260 


NODE:  TITLE:  RUN  GRADING  PROGRAM  NUMBER: 

T3.3 


Figure  C-28.  To-Be  Process  Model  EDEFO  Diagram  (T3 .3.1). 
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Figure  C-32.  To-Be  Process  Model  IDEFO  Diagram  (T4. 1). 
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T4.2.2 


Figure  C-36,  To-Be  Process  Model  IDEFO  Diagram  (T4.2.2. 1). 
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Figure  C-38.  To-Be  Process  Model  Matrix. 
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